OK Mark I just tried it on a 9436 song empeg - about 50Gb.

My force database rebuild consisted of changing the name of one playlist.

pre sift sync : 4:53
initial sift time was 18:27
post sift sync : 3:20

So not 100% like Brad but still faster. It obviously helps players with more files.

However, there was one problem! On my /drive1 it created a dodgy directory. This is a section of the inital sift...

Sifting /drive1/fids..

mkdir: created directory `_00000'

mkdir: created directory `_0'

mkdir: created directory `_00001'

mkdir: created directory `_00010'

mkdir: created directory `_1'

mkdir: created directory `_00011'

mkdir: created directory `_00012'

mkdir: created directory `_00013'

mkdir: created directory `_00014'

mkdir: created directory `_00015'

hijack: found new-style fids subdirectories

mkdir: created directory `_00016'

mkdir: created directory `_00017'

mkdir: created directory `_00018'

In the _0 directory is now a file called 10 which is the info type file. In the _1 directory is now a file 11 which is the matching mp3 file for the info file in the _0 directory.

According to a CSV export of my database (done after this song was upload I'm 100% certain) the fid of this track should have been 7172 decimal i.e. 0x1C04. So I have no idea what has happened and where it got possible 110 and 111 as the fids from. I don't understand regexps that well, so I can't see anything obviously wrong with your script.

I tried moving the files back to where they were and called them 1c040 and 1c041. I reran the sift program but this time it worked fine and put the files in the correct directory. So I have no idea what went wrong. I haven't listened to the particular song in awhile so it may not have been stored properly, although I didn't receive any sort of database errors via emplode.

Anyway thanks for doing it. It still sped up my rebuilds.