Jemplode Feature Request: Replace Tune?

Since I'm now using hierarchical playlists on the Jupiter, I'm now committed to using Jemplode to manage its files. And I'm currently in the position of wanting to replace one of the tunes stored there.

I want to replace the tune in situ as opposed to deleting it and re-uploading it. Because the tune exists in several playlists and I do not want those playlist links to disappear and have to be re-created by hand.

Emplode has a great feature where you rightclick on the tune, select "Replace Tune", and it grabs the tune from your hard disk and re-uploads it to the exact same FID without destroying any playlist links.

Mike, you've been really busy with all the recent feature additions to Jemplode, so I would understand if this were too much to ask right now. I just wanted to throw it out there in case you had a some time to look at it the next time you were fiddling with Jemplode.

and re-uploads it to the exact same FID without destroying any playlist links.

Actually, it does schedule a delete of the old FID, and creates a new FID for the new copy. It's just careful to find every playlist that it's in and change them all as relevant. At least, that's how I remember it working.

I actually have the code for this written, just no UI ... I needed to do this for supporting soups on the Karma (theres a .soups file on taxi that I routinely replace the contents of) I'll just hookup a simple UI to it.

Uploading new version now ... You caught me in a moment of "I don't want to work on C++ right now" so I switched back over to jEmplode and added that in

Mike, you are DA MAN!

Hey what's the link to download the JAR file?

http://www.inzyme.com/rio/empeg/jemplode.jar

Worked a treat. Thank you!!!!!!!

Dunno if this was a fluke, but after the synch, I couldn't connect to the player through either emplode or Jemplode. It would show up in the discovery box, but it would either sit there instead of downloading the database (jemplode), or say "The player appears to be no longer connected" (emplode). Cycling the power on the Jupe took care of it. After the power cycle, everything seemed OK including the file I replaced.

I didn't even know this was possible in emplode! Cool!

Yeah me neither or I would have stolen the feature much sooner

Hey, what happened to fast database rebuild? :-(

jar is much smaller than 52 and never gets past "downloading database" (or whatever it says there)

just me?

It's much smaller because I was accidentally including the PSD file for the splash screen which was like 1.2M Not sure why it would not download your database though, as nothing has really changed about that in the past couple releases.

I could never get fast rebuild to reliably work, so I killed it ... I may bring it back sometime, but it was a lot of nasty code for something that only sometimes actually worked.

Yeah me neither or I would have stolen the feature much sooner

Wow, I can't believe no one mentioned it before! I've totally been wanting it in jEmpload but figured there was a good reason it wasn't there. I suppose not knowing about it is good reason enough!

Aha. No, it happens with jemplode 52 also, which means presumably something else caused it. Guess I'll try tcpdump and see what's happening.

How's it supposed to work? I select a tune, hit Command-R, select a tune to replace it, and nothing appears to have been uploaded (and the song sizze didn't change)

Also, I notice I'm now getting an error when the empeg rebuilds the database, something about retrying too many times (but the empeg is already happily rebuilding the database when this happens, and so finishes in its own good time)

Perhaps I should go back to jemplode 52 and let it build my databases, it seems to have worked

How's it supposed to work? I select a tune, hit Command-R, select a tune to replace it, and nothing appears to have been uploaded (and the song sizze didn't change)

To be clear, that's "nothing appears to have been uploaded during the sync I do after that"

I went back to 52. Ability to build databases off my memory-overburdened player is too useful to give up.