Quote:
Quote:
drwxrwsr-x 2 root 60 1024 Mar 7 01:12 _0a2c2

Woah, how big are your FID numbers? The car-player expects the FID numbers to be smallish; the database takes up one byte per unused FID below the maximum, and so the maximum wants to be pretty small. Optimum memory usage occurs when the FIDs are dense from 0x100 onwards.

Ah, I may have missed an important factor here.

Are you saying that the fids really need to be contiguous (from 0x100) as the database file has to include the space for EVERY FID, whether it exists or not?

In that case I'm way off track. I start from 0x100 for the Master Playlist and then skip to 0x200, 300 etc for other top level playlists (0x640 max), then from 0x1000 for Art/Alb playlists (lots of them), then from nearly 2 million for the actual music files since the numbers are based on their inode, plus a constant (1 m.) to ensure there's no clash with the other numbers.

This means that there is no clash of numbers, but obviously there are big gaps in the range of fids, so if the database stores ALL the fids, then I'm being very wasteful.

A similar scheme works perfectly for my Rio Receiver music server, but that doesn't seem to care about discontiguous fid ranges, they're just ID numbers.

As you may remember, all my data is taken from iTunes which of course has its own numbering scheme for playlists and music data files, but irritatingly it has a tendency to re-number them, particularly after an iTunes update, so they're not much use for this purpose.

Are the problems with discontiguous fid ranges limited to the database?