So I started playing around w/ rebuilding the db in jemplode ... But I've sort of hit a brick wall. To properly rebuild the DB, I believe I have to download each *1 file. To do this, I'm using Hijack's FTP server (I need to be able to list all the available files and then grab the contents of each one). The problem is that it's taking me 219ms per *1 file, which adds up pretty damn fast to the point that I think this will actually be /slower/ than letting the Empeg do it itself ... If anyone has any ideas/suggestions/rants, I'm game.

In the case where I have a PlayerDatabase loaded in memory, I can bypass that downloads and rebuild in memory ... Maybe I just have to support both impls to do it right. In the case like alpha5, I can't load the database to rebuild from memory so I have to fallback to the slow way, but after a sync, maybe I can just depend on my in-memory version. The in-memory rebuild might cause some weird race conditions, I imagine, but 99% of the time it would be correct .

ms

I think you'd want to only support a partial rebuild e.g. one where you update to reflect changes you made in jEmplode, and otherwise (full rebuild) let the player do it, as that will cover probably 90+% of rebuilds anyway?

Does it help to do an 'mget *1' to retrieve all playlist fids at once instead of individually retrieving fids? Seems like that may be a bit faster.

-Mike

probably the best way is to get mark to implement a SITE command that actually initiates a download of all the *1 fids in tar format.

Just a word of warning. This will get really ugly on very large players with lots of FIDs... Is this something that can be done once, during an initial setup? Then you can keep a mirror copy of the database locally, saving the download time.

yeah, fetching all of the *1 and playlist files will be much slower than having the player do it locally. I wouldn't bother implementing that method if I were you. The reason the player takes so long, is that it also is trying to read all of the *1 files, and this just takes a ton of (very slow) random seeks across the disk(s).

Cheers

This is what I would have suggested.

Wouldn't it be easier to just use the existing player DB? It's in there already. If think something has gone wrong then you can force it to rebuild the DB from the *1 files.

We know what has changed and what wasn't so updating the DB should be fairly easy.

It would be compatible with Emplode as well. Emplode will just regenerate the DB from scratch.

the problem lies with cases like v3a5, where it can't create a database by itself. we're all just looking for a way to bypass dependence on the player software to rebuild in all scenarios.

Paul, I think this is a good idea, also because it could be coupled with some sort of backup system.

Basically, one may create a copy of all the 1* fileslocally and simply compare them with those on the player (size, date, last access, or whatever), and download only the new ones. If this is fast enough and gets implemented, then the same method could be used to create a backup locally of all the actual mp3 files and operate on them in the same way. It would be the user to chose whether to simply create the dbase locally or have a backup session.

Just my 5 cents