Basically, the original player application was hard coded with specific limits in mind. No one ever expected (or planned for) multiple 100+ GB drives in the empeg when it was first delivered. Remember - the design was based on 10Mbps, USB1.0, 16MB RAM and the largest shipping drive combination was 60GB (dual 30GBs).

This hard coded limit was based on the design of the player application - using a "scratch partition" of a specific size (I am too lazy to look it up right now), and using each sector in that scratch partition to directly map to a specific FID.

So, now that larger drives and larger collections are available, people are starting to hit that upper bound. They have too much music on the player... In most cases, this does not really hurt anything. The dynamic partition data is out of range and requests to read or write to it error out. The player software does not mind and goes about its business.

The only time this really becomes annoying is when you try to sync. (At least, this is where I personally first noticed it.) Because the FID is out of bounds, emplode would crash on each sync. But the player software would successfully rebuild the databases, so things were okay.

With Roger publishing upgraded, manual steps for doing a disk build, and for Mark putting an updated builder together supporting large drives, the dynamic partition size is not a problem anymore. But the limit is still hard coded in the player application (2.0, 2.01, 3.0a11, etc.).

Maxfid.v7 basically edits the binary of the player application, changing the hard coded limit to a new value. This value is calculated by the maxfid.v7 program.

Basically, that's it. Maxfid.v7 does a poke/zap/bit-edit of the application binary to change the hard coded number to something a bit more large disk friendly. That is why it needs to be done with each player installation but not with each hijack update - you are physically editing the player binary file.

Does that help?