But even using hard links, soft links etc, and then automating all that, it's still not very good compared to:

Rsync (from the player to the pc) the symlink farm, which includes the database files.
Remove symlinks from the current symlink farm.
Run a selection routine, this generates a filelist.
Create new symlinks based on filelist.
Rsync (from the pc to the player) the symlink farm.

One thing that is nice, is that it's about as few steps as possible. And the only "cludgy" thing is that rsync doesn't take a filelist, that would be ideal.

The main thing is that I can transfer database changes back from the player to the pc, and then use information gathered there to pick the songs that are next.

Correct me if I'm wrong, but the writeable parts of the database are, to my knowledge, a big binary blob on that extra partition right? That's not as fun to play with as a simple text based one. Granted my current implementation isn't so fast, but it's fast enough (start up tiime -- defined as starting of music playing -- is a hair faster than the default player. But it does take about 30 seconds to finish reading the rest of the database).

Anyway, an easy to work with database is one of the reasons I wrote Squash. The second was to improve the shuffle mode (which is 95% of the time what I used). And the third was to support OGG's since that meant I could have more music on the player (I went from 3200 MP3's to 4000 OGG's). The last reason was so I would have a player at home on my pc (Squash runs on the PC (using console/ncurses), not just the empeg).