This might be too geeky even for the FAQ, but FWIW here are the exact calculations.

A running-order will survive a reboot if it fits in the Bookmark Zero area of the dynamic partition. It is stored with eight bytes per distinct fid in the running-order, plus four bytes for each occurrence of each fid in the running-order. Or, alternatively, it's eight times the length of the shuffled playlist, plus four times the length of the unshuffled playlist. If each fid is in only one playlist, that's 12 bytes each. The Bookmark Zero area is 261,632 (0x3FE00) bytes long without set_empeg_max_fid, and 532,776 (0x7FE00) bytes long with it. So the absolute maximum is 261,632/12 or 21,802 songs as standard, 532,776/12 or 43,648 songs if hacked. If each song is in two different playlists (perhaps you have them organised by genre as well as artists), the hacked maximum is 532,776/16 or 32,736 songs.

The play-count storage size in the stock player is 28,672 fids long (one sector is used per fid). The size you get after using set_empeg_max_fid, though depends on the size of the dynamic-data partition. The builder image sets this at 16Mbytes, but this figure is rounded up to the nearest whole cylinder. Disks larger than 8Gbytes typically have a geometry with 255 heads and 63 sectors, so each cylinder is 255*63 sectors, that's 16,065 sectors, just under 8Mbytes. So 16Mbytes rounded up to the nearest cylinder is three cylinders, or 48,195 sectors. The first 4,096 sectors are used for other things (including the bookmarks), so that leaves 44,099 for dynamic track data. In this case, only songs -- not playlists -- ever have dynamic data, so in theory it'd be OK to have fids beyond the 44,099th as long as they were all playlists. However, no transfer software I'm aware of takes any care to give playlists high fid numbers and songs low ones, so you're likely to get in trouble as soon as you've got any fids beyond 44,099.

Peter