seeing as though 100GB drives are to be available soon....
is there a hardware limitation on the MK2 with respect to harddrive capacity, i.e. drives larger than 100GB,
Im sure people are going to install 2 100GB HDDs....
or is this just a software issue which can be rectified with a ROM flash update.

Only concerned cause I work for a Service compay and we service laptop computers, there are some laptops that DONT support drives larger than 40GB, even new ones..

cheers,
Jai

Greetings!

When I upgraded to my current configuration (2 x 48GB), there were some concerns raised that the disk builder software may not handle it. I did not have any problems, but that does not mean that it will not happen for larger drives. Unfortunately, since the new drives are not out, there is no way to really test it gracefully without:

a) opening the unit
b) getting a special cable adapter to convert to a standard drive connector
c) rig up a bare ATA drive and power configuration
d) attempt to run builder on it

I know that there were discussions about builder being updated to handle the newer drives. Does anyone at empeg know the status of builder? Can it (officially) handle the 48GB drives? Is there a documented procedure for building the partitions / configuring manually? (That would be a great thing to add to that "common repair" FAQ and walkthrough you are developing!!!)

Paul G.
SN# 090000587 (96GB Smoke)

I don't think we support drives larger than 128Gb (that's real Gb -- the figure is more like 137Gb in disk manufacturer gigabytes). Up to that there shouldn't be a problem, although we haven't tested the software with tune databases as big as that (256Gb ~= 64,000 songs)

Peter

I don't think we support drives larger than 128Gb
by that you mean you don't provide support (customer support) for that configuration, or there is a HARDWARE limit in respect of HDD capacity.

There's no *hardware* limit in that there is no BIOS. We can use whatever maximum capacity the linux kernel (currently 2.2.14) can handle.

Obviously, there may be other limits like the maximum ext2 partition size, or the maximum the DOS partition table can handle, but these could both in theory be changed for formats that could handle bigger disks if this ever became a problem.

The main issue is RAM use for large databases. As the unit stores the database in RAM (because it may need to access it when the disk drives are spun down) this limits the maximum number of tunes. RAM is taken from the audio cache to hold the database, so you will just notice the drives spinning up more often as you put more and more tunes on there. The mk2a (rio) players have more memory - 16MB as opposed to 12MB on the mk2, which will help here.

Hugo

Hi Hugo.

How much memory does the database use for each tune? Is it fixed size, or dependend on the actual tags? How many tunes can you fit in the approx. 6MB that seem to be available as a cache?

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Depends on the tags. Add up the length of all the tags (ie, the right hand side of the "=" in the *1 file), add 2 bytes per field and that's basically the packed database. There are other in-memory databases too, ISTR they're not very big (32 bytes/tune, maybe). Don't have the source in front of me.

Hugo

Hi.

So roughly speaking, this will be about
Song title
Artist
Source
Genre
Year
plus some hidden fields (last played etc.), let's assume that are about 8 fields, each about 30 characters long (including the two bytes you mentioned), plus some bytes for other databases, this would add to 8*30+32 bytes = 272Bytes. As Most songs certainly won't have 30 characters in each field, I think we could savely round that to 256bytes/Tune. Hmm, this would mean 4 tunes per kilobyte or 4096 tunes per Megabyte. I guess that about 3 megabytes could be used for the database without affecting the player too much, right? That would be about 12000 tunes. Based on my own empeg's data, this would "only" mean 70 Gigabytes (I have 1800 tunes on a little less than 11 Gigabytes). However, my database also shows that the average *1 file is only about 120 bytes long, so almost twice at much would fit in the RAM database.
Oh well, this might be different for others, but for me this means that I won't worry about that for quite some time. My >100 hours of music will certainly grow over time, but most certainly not to that size.

cu,
sven

proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

It's probably even better than that. I have some 4000 tunes and 500 playlists on my 18 GB, with total length of *1 files around 750kB. However, /drive0/var/database is just over 450kB (bacause of all those unused 'left sides' in *1 files). So, with my usage pattern it would take some 120GB and 25000 tunes to grow the database to 3MB.

Then again, if I had my tunes fully tagged, the numbers would be closer to yours. Heck, those 2a's additionaly 4MB would come handy...

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Greetings!

If it is of any help, there is no problem at all with my hard drive / database size. If you want to try and extrapolate it out... (Just for the record, all of the playlists are really untagged, but the tunes have artist, title, source and genre filled out.)

Approximately: 13,000 tunes; 1,600 playlists. Unfortunately, I am currently doing other things, and cannot give you a database size. I will post tomorrow, if you would like. In any case, this is all running on an empeg Mark 2_. That extra 4 MB in the 2a should more than cover any differences.

There are no performance or memory problems I have noticed. The only thing I notice is that it takes a few extra seconds to cold boot.

Paul G.
SN# 090000587 (96GB Smoke)

Greetings!

The database is just over 1.5MB.

-=-=-=-
empeg:/drive0/var# ls -al
total 1577
drwxr-xr-x 2 0 0 1024 Sep 26 20:27 .
drwxr-xr-x 6 0 0 1024 Jul 26 18:43 ..
-rw-r--r-- 1 0 0 334 Sep 26 20:27 config.ini
-rw-r--r-- 1 0 0 1533236 Sep 26 20:27 database
-rw-r--r-- 1 0 0 68536 Sep 26 20:27 playlists
-rw-r--r-- 1 0 0 342 Sep 26 20:27 tags
empeg:/drive0/var#
-=-=-=-

Paul G.
SN# 090000587 (96GB Smoke)