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.



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.



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?)