Hello,

I need the tag file from /var/empeg. Can someone please upload it? My empeg is off line so i can't download it directly

Thanks,

-Scott

The "tags" file? This is generated automatically by the player as part of a "sync" from emplode.

And, more importantly, it's not static -- the contents vary according to which tags were found in your metadata (*1) files, and are tightly coupled to the contents of the database (or database3) files. A 'tags' file doesn't make much sense on its own.

That said, if you just want to see one, go to my documentation on the subject and scroll down to the "tags" section.

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

And it might not be of any use to you

That said, the one from my player is on that page. It was generated by emplode.

Yup. I tried the order of the tag file from your webpage. I rebuilt the database and my pbDance player works with either tag file. But empload still doesn't work.

Anyone in the (south) bay area with an empeg I could borrow for a couple of hours or at least drop by and do some packet sniffing?

My empeg arrived from San Diego yesterday. I problem solved with a little wireshark packet sniffing. The player_type (FID 7) must be sent as "rio-car". I was sending "Empeg Clone". This was causing empload to mark the player type as "unknown" and then not allow nested playlist. Emptool and Jempload didn't care.

With this fix, pbDance supports empload, emptool, and Jempload.

It's "emplode" and "JEmplode", as in "implode" or "explode". Sorry ;-)