Greetings!

Cool! No worries.

Parts of it are in the FAQ, but I do not know if it references the high FID count issue. I am sure that the process could be cleaned up and streamlined a bit - I was kind of distracted when typing that out.

Basically, the player application is able to rebuild beyond that high FID point, but the sync procedure cannot. Emplode times out and crashes, while the player attempts to build the databases, but never saves them to disk. I am guessing that there is a test for the FID number being above a certain point or it is beyond the amount of memory allocated.

Either way, the practical aspect is that you can push the player further, but you have to be prepared to manually rebuild the databases. The fidsift.sh is actually optional - the databases will rebuild properly, but I like having the directory structure neat and it avoids any glitches.

So, the trick is:

a) sync normally, knowing it will crash.
b) let the player try to complete building, knowing it will not save the database
c) drop to shell
d) read/write the partitions
e) fidsift.sh for cleanliness
f) read/write the partitions
g) run player from command line
h) allow player to rebuild databases, this time it will save them
i) quit the player application (q or control-c)
j) set the filesystems to read only
k) exit and reboot

By the way, welcome to the wonderful wacky world of unexplored territory!!! I suspect that you may see some strangeness in the dynamic data associated with files that are "over the edge", but I have never experimented to prove it. You should not notice any trouble with general use of the player though.

One other random emplode glitch that most people do not see. If you try to sync a huge number of playlists, you will also crash emplode. Again, I suspect that it is based on the memory allocated as opposed to a specific check. I found this trying to rebuild a large-FID player from scratch. The number of playlists (the first items sync'ed) overwealmed emplode in rather amusing ways...