I didn't ask for the format, I asked for the file

I'm pretty familiar with empeg data structures having written pbDance back in 2003 (aka New player App), long before most of the "documentation" was published. I reverse engineered the protocol from the linux emptool and some help from Peter. pbDance is a complete Jemplode/empload client (i.e. empeg clone). I am in the process of updating it to 0.3 and adding in support for my Seeburg wallbox interface. It is all running on a raspberry pi. But in the process, I broke empload support. The error I get is that empload doesn't like nested playlists,sets the length to zero and then complains that the length is wrong. It works fine with Jempload.

The need for empload is because I have an obscure bug with Jempload when it sends large fids to my client. My client sees a number of 16384 byte fid write opcodes and then sees a 2048 byte bad opcode. I want to see if empload causes my client to do the same thing... But somehow, ten years ago (2003) I broke empload support (but I swear it WAS working).

Back to the OP... The last time I copied /drive0/fids and /var/empeg from my empeg to my rpi, I noticed that I had to rebuild the database before pbDance would work. That meant that my tag order was different from the tag order in the empeg. Strange. Rebuilding the database applied my tag order, so the original order was lost. My empeg is in San Diego, and I now live in Palo Alto, hence the request for a tag file. I wanted to check if there was some unintentional tag order that empload expects. Since it creates the tag order, it may not "like" other tag orderings. Just a guess...


Roger,
Back in 2003, I posted a request for the scratch partition layout. It was something like 512 bytes per song * 65536 songs. Do you have the link to that data structure? I'm pretty sure it was posted after my request, but I can't seem to find it. (IIRC I think it was in the FAQ)

Thanks,

-Scott