Can you reproduce this, using a subset of your collection and a test fid dir?

I doubt that XFS randomly reassigns inode numbers whenever it feels like it

It's unlikely, but not impossible. This is easily detected. Just type ls -li in an mp3 dir, reboot and look again. smbfs on Linux turned out to give different results on each boot.

I am wondering if I am overflowing anything with the high inode numbers (the latest songs I just added all have inodes in the 373 million range)

There's nothing that can overflow anymore (at least not sooner than with other tools). A tune is now uniquely identified by a string built by the major and minor number of the device holding the filesystem containing the tune and the inode number of the tune. This string is used as a key to look up the fid number in a gdbm database. using -d dimMsS debug options you can follow all gdbm activity.

In theory, a 64-bit inode number (yours still look like 32-bit) could overflow the sprintf() function, but then still it would come up with a unique string.

So I can think of a number of explanations for this behaviour:
- your filesystem does not have persistent inode numbers
- you somehow lost the mp3tofid database
- you used the -n switch to force generating a new mp3tofid database
- the major/minor number of the filesystem changed caused by fdisk or lvm operations
- a weird bug

If you did lose the mp3tofid database, by accident or by using the -n switch, try restoring it from the player. This is why it is backed up there. Restore it, delete the fids on your host PC and run mp3tofid again. mp3tofid will have to scan everything again, but your fid numbers will be back to what they were.

Pim