I read on the forum that there might be an issue with the amount of songs (to be exact, the amount of fids) I am planning to use.
It's not the amount of FIDs exactly, it's the RAM those FIDS take up. So as you already surmised, one thing that will help is to carefully strip every file of any unnecessary tag data. For example, if you have the "Comments" field filled out on all of your songs, strip them all out now. When all that data gets concatenated together, that's your database file size. By the way, make sure to do your tag cleanup *before* attempting to install the songs onto the player.
For that large of a song set, though, doing this will only be of marginal help. But it will help some. All it's going to do is increase the number of songs that will work in a single shuffle, but you're still going to have to break things up into smaller groups even if you do that.
No, Japie is correct: the number of songs that will work in a single shuffle (i.e. the problem with not remembering a large shuffled playlist over a reboot) is, indeed, to do with the amount of fids, not the total database file size.
Having a really large database is a different problem, as it takes up memory that would otherwise be used for caching. So a 35,000-song player would access its disks more often than one with fewer songs. If the database gets TOO big, there's no room for cache at all, and the player will fail to run. That limit is about 6Mbytes on a Mark 2a player; about 170 characters per song with 35,000 songs. It is much less on Mark 2 and Mark 1.
If you can figure out a way to split that into three groups of 33% each, that's going to be the most reliable way. Then you can reliably play one of those three groups, and the player will do all of the expected things, like remembering its song position when you restart your car.
I don't recall what happens if you try to shuffle-play all 35,000 songs, but I'm pretty sure one of those things is that it won't remember its play position or the shuffle order after a power cycle. If I recall, though, you're perfectly OK to shuffle the whole thing if you don't care about that feature and don't mind reshuffling after a power cycle.
Someone correct me if I'm wrong there.
There's no need for smaller splits if using set_empeg_max_fid. With that, the 80%, the 20%, and even the 100% should all play fine.
If I'm recalling correctly, all this particular thing is going to do is to *slightly* increase the available size of the dynamic data partition, but it's not going to increase it to 35,000, so you still have to break up your playlist into groups that will fit inside this max_fid size (whatever that is). I don't think it's as big as 20,000 even, so I don't think your 80/20 split idea will work even with the max_fid hack. (Someone correct me if I'm wrong?)
Fortunately for Japie, I'm afraid you're wrong; with the set_empeg_max_fid hack, the "single shuffle remembered after reboot" limit is somewhere over 43,000 songs (depending a bit on how many playlists each track is in). Without the hack, the limit is about 21,000 songs.
The other limit on fid numbers, also ameliorated by set_empeg_max_fid, is the dynamic data size, used for storing play-counts and other, well,
dynamic data. This is about 28,000 fids big by default; how big it becomes after set_empeg_max_fid depends on the exact disk geometry, but for big disks is typically about 44,000 fids. (That number includes playlists, though, so Japie is getting close on that one.)
Peter
Previous Topic
Index
