I'd really like to have a cancel button on the Sync screen. Sometimes I'll hit sync and see it copying files I don't want it to copy (because I dragged them on accident for example) but there is no way for me to cancel, so right now I just unplug the thing and then I have to wait for it to realize that it's no longer plugged in. I'm sure unplugging it while it's syncing really isn't good for it.

Stopping the sync process in the middle will tend to corrupt your database, sometimes requiring this procedure to fix. Hence the lack of a cancel button.

Think of it like saving a large file to your PC's hard disk. You wouldn't unplug your PC in the middle of a file/save would you?

Next time you notice a mistake after hitting the sync button, let the sync complete and then correct the error afterward instead of panicking and pulling the plug.

The way it works now is wrong. Anything that can take hours to complete needs a CANCEL button, and it's pretty easy to add one to JEmplode if we cannot get it from Emplode.

There is no good technical reason against it, and saying "that's not how it works and the way it is now is best" just doesn't cut it either.

Cheers

Well, there's no good technical reason against it, but I think the cancel should DEFINITELY have a confirmation dialog that says "doing this will require you to rebuild your database" blah blah blah.

Oh yeah, and it should wait until the current song is finished uploading, too.

There's not a chance we would implement such a control unless it took care of cleaning everything up for you. Should that include getting rid of all those now-obsolete playlists it created right at the start of the session? Probably..

Rob

Good points, Rob!

The cleanup can be minimized by sending stuff to the player in the correct sequence, requiring one playlist deletion/truncation max, I think.

Cheers

The cleanup can be minimized by sending stuff to the player in the correct sequence, requiring one playlist deletion/truncation max, I think.

Nowadays we could get away with sending all the playlists at the end -- i.e. now it's not an error for a song to be in 0 playlists. But I think one deletion/truncation is optimistic for a cancel in the middle of downloading playlists (at least if you don't want to orphan any playlists).

This is bug 79 in Empeg's internal bug-tracking system, which gives you some idea of its antiquity. It'd be too big a change to get into 2.0, but hopefully would be one of the first things looked at after that.

Peter

What you need is a total lack of quality control and the blind confidence to add in huge features in every release -- then you'll be just like jEmplode

I'm going to take a look at this for the next release ... Since this code is almost straight from Emptool, I'll post the source to my changes if I can get it to work better -- maybe it will save you guys some time.

Mike

So that works -- It puts all playlists off to the end and I added the additional catch that you can't cancel while uploading playlists (since you can get the same sort of weird problems)...

The only issue is that, at least currently, after you synchronize, it automatically redownloads. The potential problem here is that if you cancelled, you have dirty nodes that are not yet synced, but if it redownloads, you will lose those unsynced nodes.

There are a couple possibilities here: 1) lose them, who cares, 2) on cancel, don't redownload -- which may leave the UI out of sync with the Empeg -- at the very least, code has to be added to FIDLocalFile.synchronize to replace itself with an FIDRemoteTune after syncing, so if the database doesn't reload, it will be correct, or 3) redownload but try to "put back" the dirty nodes -- this is a big pain in the butt, so I hope it isn't this one

Mike

If all playlists were sent together as a unit near the end, then cancelling there would not be a big deal -- I expect that the time required to send ALL playlists will be less than the time for a single (typical) MP3 file upload.. so maybe just never cancel in the middle of doing playlists. For serial, this wouldn't be as pleasant as it could be, but for ethernet/USB it should be no issue.

Cheers

OK .. I chose the route of not reloading the database on cancel, but rather making the FID* classes cleanup at the end of the synchronize method. Basically the changes were:

FIDLocalFile at the end creates an FIDRemoteFile with its tags (replacing itself) and unmarks dirty

FIDRemoteTune unmarks dirty

FIDPlaylist unmarks dirty

FIDDeleted removes itself from the database (and unmarks dirty, but this is not really necessary since its gone)

Mike