Anyone happen to know how you rebuild the playlist databases from scratch? If I delete /empeg/var/playlists, somehow the Empeg can reconstruct it ... Where is the source data for that?

ms

That file gets rebuilt as part of any "normal" database rebuild. The data within is just a catenation of the *0 playlist files from the fids directories.

Cheers

I'm retarded ... I completely forgot that the *0 files for playlists contained that data. You'd almost think I didn't write the code to create those files in the first place. Thanks Mark.

OK, so we'll see who responds faster -- you or Peter :

So I've got jEmplode creating all the db's itself now (in the update case, not in the from-scratch case) -- and I might add it's pretty damn fast. Only one thing is standing in my way releasing it right now, and that's the dynamic database. I don't see any way to do a mass replacement of it. There is a magical FID that I can request to DOWNLOAD it, but when I try to upload using that same FID, it appears to ignore me. Incidentally, it appears that I can't upload ANY of the magical FID's using the protocol -- I had to use hijack+ftp to uplaod them, but I don't see that I can do that with the dynamic database .... Any ideas? Is that stored in a normal file somewhere, or could you give me a /proc file to replace that (or do you have one already?)

ms

What is the "dynamic database"?

So long as one uploads (FTP) new files for /empeg/var/{database,playlists,tags} and then restarts the player, all should be well. Or should it?

Cheers

Normalization, Play Count, Play Last, BPM, Skipped Count, and Marked are all stored in the "dynamic database" which is writable while the player is running, which I assume means it is in flash memory somewhere ... So the data isn't stored in tags, playlists, or database3, unfortunately. I suppose I can just ignore it for the time being. Maybe it isn't rebuilt by a normal database rebuild anyway?

ms

I think all of that is ignored during regular database rebuilds, so yes.. skip it for now (and possibly forever).

Happy New Year!

All of that data is on disk, in the dynamic data partition. One sector per FID or something like that. There was another thread about how to parse it here once.. I don't actually know if the player bothers with it or not on a sync -- could find out I suppose, by monitoring disk accesses to that partition during a sync. But there are other ways the player could maintain the data, so.. ??

Cheers

During a sync, I can definitely send individual ones back (or at least I'm supposed to be able to -- I think there maybe a bug right now), but it looks like I can't send a bulk write back (ala rebuild). No biggie, I guess.

Well, just the individual ones for things that changed should be good enough.

cheers

I already send the individual ones during a sync, so I suppose it's possible that there isn't actually a separate index for that data and by updating the individual ones, I'm actually writing to the single datastore for that data.

ms

If I recall correctly (always in doubt..), the dynamic data partition is simply organized, as a huge table indexed by FID. So long as Jemplode is updating the individual FIDs, that should be all that's needed.

But perhaps Peter may chime in with better information here.

Cheers

The special FID for the dynamic data is read-only. The player will ignore you if you attempt to write to it. It may not report an error, I don't recall.

To write the dynamic data, you have to use the specific F-suffixed FID for each track.

Thanks Roger ... For the record, It's looking like it doesn't give an error if I try to write to it.

ms

I already send the individual ones during a sync, so I suppose it's possible that there isn't actually a separate index for that data and by updating the individual ones, I'm actually writing to the single datastore for that data.

Ees so. Dynamic data lives only on the dynamic partition and no "rebuild" is required, either on v2 or current v3-alphas. If you're written the *F files for all your new fids, you've done all that's necessary for the dynamic data.

At some point in v3 we'll switch to protocol2 and the whole static/dynamic distinction will go away as far as PC-side code goes, becoming an internal implementation detail of the car-player. Exposing the actual on-player database format to the PC was such a wrong wrongety-wrong-wrong wrong thing to do. Er, IMO.

Peter

In reply to:

---

At some point in v3 we'll switch to protocol2

---

You said it, not me

In reply to:

---

Exposing the actual on-player database format to the PC was such a wrong wrongety-wrong-wrong wrong thing to do

---

Yeah ... I tend to agree. I much prefer Protocol2's way. In the meantime, though, it sure is fast rebuilding on the PC

ms

Exposing the actual on-player database format to the PC was such a wrong wrongety-wrong-wrong wrong thing to do.

Particularly when it resulted in the nasty hack that is the Rio Central forking over a database to emplode...

Particularly when it resulted in the nasty hack that is the Rio Central forking over a database to emplode...

Yeah. That was truly gross. Particularly as we had to do it twice as it asked for the size first. When it came to Karma we gritted our teeth and threw the whole damn thing away in favour of protocol2, and it still all turned out -- I bet -- less work than we put into lashing up protocol1 for the Rio Central. Ahh, hindsight...

Peter