Your bump should mention that the message it's a reply to was updated

I guessed that was why and went back and read it. Impressive.

Valid point. I forgot that bit.

I was impressed by the database build improvements. Much faster!!!

I'm bummed out that you can't do a sync from emplode still...

Well, with the audiobooks, I know that if I actually worked on it, I could condense the ones with 99 files per CD to something smaller, and basically clean and rebuild the player so that it did not have that many FIDs on it. But it does not clear the problem.

Basically, it seems that emplode launches the database rebuild, but that some error is passed or something happens where emplode thinks it finished insanely quickly. It then moves on to the next step (writing player configuration) and fails with a timeout. While all this is happening, the player is rebuilding the database files, but never actually succeeds in writing them to disk, even though it goes through without a sign of an error.

In all honesty, I have not played the most recently added files much. When I tested with a few random known "last files", though, it seemed to work okay.

Most impressive player stats, Paul!

Good to see the database rebuild times are somewhat improved by this change! As in they now take around 33% of the time they previously required!

Pity about Emplode. I suppose JEmplode probably survives this test though..

Cheers

Um, actually I have not tried jemplode recently. I usually sync over USB to the player from Windows 2000. When I tried that, long ago, the combination did not work well at all. So I have been using emplode all along.

I can add tracks and all, and (to be honest) I do not sync much. I have my playlists fairly static at this point, and the rare random change is not that big a deal.

Edit: correcting typos.

(2) 30GB HDD
2.0 developer
emplode via ethernet
Hijack 344
10235 Tracks

---Before fidsift.sh---

21 seconds: boot up time to standby from power off
8 seconds: load database into emplode
4m57s rebuild database - sync (deleted a track from a playlist)

---After fidsift.sh---

21 seconds: boot up time to standby from power off
5 seconds: load database into emplode
2m20s rebuild database - sync (deleted a track from a playlist)

A 47% improvement in sync time!!!

Awesome work Mark!!!

Also, using Emplode for some strange reason when I sync for the very first time after having read the db, the sync goes through but does not complete (as in, no database rebuild, changes made in emplode are not reflected after database is read again). Subsequent syncs work fine. I have become used to just syncing the first time when I get in to emplode, but it would be nice if I didn't have to do this as it wastes time. Any ideas?

I used to have various issues syncing, so now every time I go to make any changes (new music, corrections etc) I first telnet in and kill off everything I find using ps that isn't needed. Some of these are obvious like emphatic, but there are occasionally others, depending on what I have on the machine.

After doing that syncs work fine. Admittedly I only have about 7000 fids so not a huge collection.

Greetings!

This is more likely based on the open processes. If any of them have log files (or anything else for that matter) locked open on the standard root or music partitions, emplode (jemplode) are unable to dismount them as part of their normal sync process.

Shouldn't those programs be set to turn off when detecting a sync?

Yes - I should probably have plonked these apps elsewhere, but never mind. Maybe when I rebuild with 3.0 beta (I'm not risking it until at least beta stage) I'll rebuild a more sensible structure.