Mark 1 upgrade

i am considering buying a mark 1 with a 3 gig drive. can this drive accept larger hard drives (20 gigs?). I understand there is a clearance issue with the height. Is there anything about the mark 1 that doesn't size up to the mark2?

thanks in advance

Differences between the Mk1 and the Mk2 are listed here.

Details about upgrading disk drives are here, including all size, capacity, and clearance data.

Please skim the FAQ before posting questions.

There should be NO capacity limitation, just the drive height restrictions. Any normal "slim" laptop drive will work.

Current Empeg/Hijack kernels support drives up to 128GB in size. If/when we see larger ones in the 2.5" size, I'll tack on "48-bit LBA" support to blow away that limitation (already implemented it here in a different driver for a client..).

Cheers

Can we hold you to that, Mark?

I think it's cool having you on our team.

Yeah, no problem holding me to that.

It turned out to be quite simple to implement (on the other platform).. much more so than Andre's version (in the 2.4.xx-ac kernel stream) would lead one to believe.

Actually, as soon as I finish with the current project (work), I might just tuck it into Hijack while it's still fresh in my mind.

Cheers

There is, really, a capacity limitation; the amount of RAM in the mk1 means that you start to run out of caching room if the database gets too big. Personally I wouldn't put more than about 40GB in a mk1 - and people with twin 60 setups would want a mk2a because it has 16MB.

In theory, you can upgrade a mk1 to 16MB with another 4 DRAM chips on the underside of the main board and changes to the kernel, but I don't think the player s/w will recognise it...

Hugo

Greetings!

Actually, with my old Mark 2, I didn't have any problems with the amount of RAM, except when I was running the old displayserver as the http server. Then, it would build the array in memory and run out. But in the player app it was never a problem, even with reservecache set.

Are there many other twin 60 setups out there? Just curious...

So Hugo, out of curiosity, if a Mk1 would be running out of memory at around 40GB where does a 16MB Mk2a run out at roughly?

I realise that it's not 80GB since the extra 8MB is doesn't have to hold any of the kernel or player software and is available exclusively for caching. Rough guess?

if a Mk1 would be running out of memory at around 40GB where does a 16MB Mk2a run out at roughly?

It doesn't work like that. What Hugo means is...

- Each song is a database entry.
- Each database entry takes up a fixed amount of space in RAM.
- The more SONGS you have on the player, the bigger the database.
- The bigger the database, the less room there is for caching the music.

So it's not a 1:1 hard-disk-to-memory ratio. For instance, just because you have a bigger hard disk doesn't mean you'll put more songs on it. Maybe you'll just encode your songs at a higher bit rate, and use up the disk space that way.

- Each database entry takes up a fixed amount of space in RAM.

The amount isn't fixed; a song with long database fields (title, artist, comment etc) will take up more space than a song with short ones.

Peter

Wow, I didn't realize that.

Does this mean that removing all comments (usually basic CD info etc, especially with classical music) could raise the maximum number of songs? And would this require re-upload of all songs, or is an minor database fix sufficient to remove all comments?

Although I don't have any problems yet with 40Gb (and read about Paul's 120Gb without problems), it would be an interesting issue once the someone hits this limit.

Jelle

It would require re-uploading all of the tag files, which could be triggered by simply deleting the comments in JEmplode and then hitting Sync.

-ml

Okay, while I was poking around I decided to add 48-bit LBA support to the IDE driver in the Hijack kernel. It will be present as of Hijack v274, for future use (no laptop drives are that huge yet).

What this means is, instead of the previous IDE drive 28-bit limit of 128GB per drive, the limit is now 32-bits for drives up to 2TB (tera bytes) in size, each. The 48-bit spec allows for drives up to 65536 times that 2TB limit, but all existing Linux kernels top out at 32-bit block numbering in the page/buffer/file systems.

So now the race is on.. who will be the first to attach a HUGE drive to their player..? (most likely Paul!)

Actually, now that I think about it, I suppose I could grab my 2.5/3.5 adaptor and plug this here Maxtor 160GB desktop drive in, just to test things.. MMm.. letmeseeifihavetherightpatchcablesforthis..

I realise this, but obviously Hugo picked 40GB from somewhere.

Okay, here's the drive banner from boot time:

hda: Maxtor 4G160H8, 156334MB w/2048kB Cache, CHS=19929/255/63

Mind you, that's as far as it goes for now, since I don't actually have an empeg filesystem on that drive (yet).

Cheers

And for the record, here is JUST the 48-bit LBA portion of Hijack, in case the empeg folks want to port it to some other kernel.. (hint).

(attached)

Send it to them on the internal alpha list, silly.

Done.

Heh.. my dad got one of those 160gb Maxtor drives about a month ago, and he can't access more than ~128gb of it on his Win2k machine.

Great work, Mark.

Cheers,

A.

How easy is it to get a 3.5 connected to the empeg as my GF only uses the empeg in the house due to my buying an amp for her car her not wanting empeg in car as to big to carry around other woman type arguments second amp in my car etc.

But i was thinking could i attach a big 3.5 to my empeg backup and use it as a music server for the house.

Peter, are strings shared in the database? In other words, if I have ten tracks from an album with a really long name, will I get ten instances of the album name stored? Or will I get ten (shorter) references to one long string?

(Yes, I know I ought to RTFS, but I'm lazy, and you or someone may know the answer)

I think this is in another thread that I read recently, but basically you need a special IDE cable that goes from 44 pin to 40 pin and also, you would have to have a seperate power supply for the 3.5 HD as they require a bit more power than laptop HDs.

<applause>

EXCELLENT, SIR!!!

You can never have too much hard drive space...

Peter, are strings shared in the database?

No

In other words, if I have ten tracks from an album with a really long name, will I get ten instances of the album name stored?

Yes

Or will I get ten (shorter) references to one long string?

No

(Yes, I know I ought to RTFS, but I'm lazy, and you or someone may know the answer)

Part of the problem is that RTF (Emptool) S lets you find out the database format used on the player -- i.e., we can't change it (make it more efficient) without breaking Emptool, Emplode, and JEmpeg. It's been sort-of on the todo list for a while to separate the player's database (that it uses while running) from the one visible to Emptool/Emplode/JEmpeg. This would also allow other information (e.g. original pathname) to go in the externally visible database without it clogging up the one used by the player. But that's way post-2.0.

Peter

You need something like this, which gets inserted between the drive and the host.

It works for either direction: BIG drive to SMALL host, or SMALL drive to BIG host. In either case, the drive requires external power, which for a small drive can be supplied over the power plug shown in the photo (for a BIG drive, just plug power directly into the drive).

Other similar solutions also exist.

Cheers

So of course the obvious Paulish thing to do with a Mk1 would be to install a pair of 60GB drives, and record all music at very high bitrates, keeping the database small.

But of course, the lowly Mk1 would then not be able to do much pre-buffering, since high bitrates produce large files..

Mostly out of thin air, really. The biggest Mk1 that ever shipped was 20G, so I just doubled it. As various people have said, high bitrates mean a smaller database.

You can check the size of the database, it's in /empeg/var - add the tags, playlists and database sizes together.

Hugo

Greetings!

Actually, my bitrates are relatively tame. They are VBRs, ripped with Sonic Foundry's Siren (no longer available, pity...), with VBR settings configured for best quality sound. I just happen to have a bit bigger collection loaded (highest FID = 17,182 decimal, 431E hex, combined database file sizes are just over 2MB). I think the Mark 1 could do it, just that I have never had one to try it with...

Ok, in this case, let me put the question in another way:
How large can the databases get on each of the architectures, without the player software crashing with an out-of memory-error?
Or yet another way: How much memory is available for database+cache on each of the platforms?

cu,
sven

You can measure this yourself if you want to.

Just wipe all of the music from your drives, and reboot with Hijack installed. Then surf to http://your.player/proc/meminfo and see how much is left over (MemFree+Buffers+Cached, I think).

This will be different between Mk1 and Mk2, as the software is different. And Mk2a should be exactly the same as Mk2, except 4MB more free.

-ml

In reply to:

---

It's been sort-of on the todo list for a while to separate the player's database (that it uses while running) from the one visible to Emptool/Emplode/JEmpeg.

---

That would be really cool! But I understand why other things are more pressing...

For anyone referring back to this thread, there was a bug in the 48-bit support of v274.. fixed now in newer hijack's (up to v290 today).

cheers

In reply to:

---

It's been sort-of on the todo list for a while to separate the player's database (that it uses while running) from the one visible to Emptool/Emplode/JEmpeg.

---

I will be implementing this in mp3tofid version 2. I will have to, as the database size is getting a lot bigger because of the extra tags I'm putting in (like original tune location).

I'm already able to build the database myself, so it will not be hard to leave out unnecessary tag fields.

Unfortunately I won't be able to release a new version until after I return from a short holiday.

Pim