Hello,
Emplode imports songs such that position and track number were in order. If you pressed the down button 3 times and played randomly, then unsorted the playlist, it would unsort around the album the song was playing from (if you had your filenames right).
1)With soup playlists is position important in jEmplode? If so, how do you get songs to import such that, basically, position number corresponds to track number instead of what seems to be the default jEmplode way of position number is determined by alphabetical sort of titles.
2)How does autosort on import work? what 'fields' for tag name works? ie: fid, FID, {fid}, etc.? is there a field for filename?
Bottom line: Can you get a shuffled Down Button pressed 3 times to unsort around the album the playing song is from?

Thanks.

As far as sorting, jEmplode 69 adds per-soup-layer sorting, so you could create the bottom layer that would sort by track number.

MSCHRAG,
So song position is of no importance? Which soup layer is controlling when down button is pressed 3 times?

Also,
On large databses, can the timeout be extended for the retries after reboot?

On the occasions where something has happened and the synch has failed....is there a way to avoid having the empeg "rebuild music database" and let the computer do it instead?

If you're asking if position matters in soup playlists created by jEmplode, the answers is "sort of". It matters in that position should ultimately be equal to your sort order in a soup playlist. You definitely shouldn't change the order of tunes manually inside of a soup -- that's gonna cause problems.

Is 3-down the "unplaylisted tunes" playlist? Or maybe that's tunes in the root playlist. Position there wouldn't be automatically controlled by jEmplode unless you set a sort order on Root (can you do this even? I'm not sure).

As far as the timeout on retries thing, someone else mentioned this too. It's kind of problematic, because if your Empeg decides to do a rebuild, that is totally dependent on the number of tracks you have on your player, so that could take 30 seconds or it could take 20 minutes. It's really hard to come up with a meaningful timeout. Now if someone wants to do the legwork of determining what the equation is for rebuild time as a function of number of tracks, then I could probably work that in there somehow to make it a little smarter.

For the rebuild thing, a sync failure is a case where I can't rebulid on the PC because the Empeg is in an unknown state relative to the in-memory database, so I have to fall back to an Empeg rebuild there. I can only rebuild the database in-memory when it's a succesful sync, because then jEmplode's view of the database matches the Empeg's view of the database. If the Empeg just died somewhere in the middle, jEmplode can't necessarily know in every case what the Empeg ultimately decided to keep vs toss.

MSCHRAG,

The Down Button pressed 3 times plays the entire music database.

With a large database, it is CRITICAL to avoid the "rebuilding music database" because the times involved are so long. Usually, it ends up having to do this TWICE each time jEmplode gets working which results in a massive waste of time. I would say if you could put in some kind of "smart" rebuild time as you mentioned that would go a long ways for avoiding the "rebuilding music database" problem by increasing the chance of completing a resynch. i can't recall if 16000 took 40 minutes per rebuild or 40 minutes to get jEmplode back up which is 2 rebuilds.

jEmplode 69 does in-memory rebuilds if you turn it on in Options. It just can't do it when a sync fails.

MSCHRAG,

Yes, i understand that now. I was referring to increasing the time for the resynch to occur when there is a large database in order to avoid empeg "rebuild music database" .

Also,
why does there seem to be 2 reboots at the end of a resynch? After an upload, I will hear music from the empeg a little and then it will reboot and then play as usual? Is there any way to make the music come on just one time, when it is ready?

You said your database rebuilds twice per upload? So are you saying that because the timeout expires waiting for a reboot, that somehow causes a SECOND rebuild to happen? That on-empeg-rebuild should only happen if the original sync failed in the first place. A normall process is: upload changes, jEmplode requests database rebuild (you should see the rebuild status in jEmplode), jEmplode reboots player, player reboots (and does not rebuild), player finishes loading, jEmplode reconnects to player, done.

The timeout should happen if it goes like this:
upload changes, jEmplode requests database rebuild, rebuild fails, Empeg reboots and rebuilds itself, jEmplode waits and times out.

I'm not sure where the second reboot or rebuild would happen in this process or for that matter why your Empeg would be rebuilding itself. Are there any error messages that jEmplode displays? Can you run a full sync and send me the console output from that? (also, if you would, turn off serial/usb so those exceptions don't get all mixed up with the other debug info in the logs).

ms

MSCHRAG,

Let's say on a resynch, there is a time out and the empeg is left in a state of "synchronising". You have to reboot. That is where the two "building music database" rebuilds come in.

VERY frustrating when you have a large database.

So this is the part I'm not clear on -- when you say "resynch" can you clarify? What is happening in the jEmplode sync dialog at this point? I'm just trying to think of a point in the protocol where a timeout would occur that would leave "Synchinsing.." on the Empeg. It's certainly not SUPPOSED to happen this way. There's definitely something funky going on w/ your scenario, I just don't know what yet.

I see this quite a lot. Windows XP+SP2, JEmplode 61, Ethernet connection, v3aplha7+Hijack413. Approx 6.7 GB of a 9 GB drive is used. I do have some other things on the system (ttsclock, empTelnet, web interfce).

JEmplode shows "Rebuilding music database" with approx 20-25% progress bar. Always stops at the same point.

I just put it down to the beta software.

mdavey -- So it just hangs at 25% of rebuilding? So at this stage your Empeg is just left in Synchronizing mode like he's talking about as well?

Would you mind running jemplode from the commandline (java -jar jemplode.jar) get it to hang and leave it just couple a minute or two then send me the console output?

Also, I'd be interested to see you do a Ctrl-Break (in the console) when it's hung and send me that output as well.