Replace Tune doesn't check RID's, it just always replaces (I just realized I still need to check to see if this also updates the RID if it DID change -- it probably doesn't, so there may be a border case w/ duplicate checking when you're in the same session after a replace, but that's what 58 is for )

Replace Tune updates tags (but keeps FIDs the same)

On Jupiter, leading zeros are stripped from track numbers (I don't have my Jupiter hooked up to test this, but it SHOULD do this)

i18n fixes inherited from the Karma/RMML

Is there another thread that has more detail on the i18n changes? I've had ongoing international character issues in jEmplode, and I'm hoping that this will fix me up.

You can look at the CHANGES file for RMML at rmml.dev.java.net ... Ultimately I don't send UTF8 over to the Empeg (if you use v3), so that will sort of kill things for i18n for the Empeg. Specifically what problems are you having?

Thanks very much for making those changes to Jemplode, Mike. They worked and I was able to upload those modified tunes to the Central.

What do you suggest with regard to forcing a RID recalculation on the tunes in question? Would going into each tune, deleting the Comment field, and re-synching, be enough?

It is always recalculating RIDs now and it should be overwriting them too I think (as I'm writing this I'm questioning myself, though -- I need to double check, but I think Central uploads always rewrite the comment field). The problem I was referring to was that I internally keep track of those RID's so I can quickly find matches and I believe I'm not updating that when you replace -- quitting and restarting jEmplode after replaces would fix that, but it should only be a problem in a very few border cases (RID collisions between the old tune and the newly replaced tune)

Ah, excellent. Thanks for the clarification.

Hey, since you're working on the Jemplode/RMMLite code anyway... Can I rub the genie lamp a bit and wish for something?

Any chance of adding an additional optional command line parameter to RioBackup.Jar?

I use RioBackup.jar to keep playlists synched between the Empeg and the Central. I back them up off of the empeg, then restore them onto the Central. Works great. The only problem is that when restoring, RioBackup only adds playlists, it doesn't wipe the existing playlists before restoring the new ones. This means that if I don't go in and delete the Central's playlist tree by hand before doing this, I get doubled playlists.

I understand why one might want to only add playlists, so this is still valid behavior. But I always want to fully wipe and replace. So is there any way to put an optional "-wipefirst" command line parameter onto RioBackup?

By the way, if I use Jemplode to delete all the playlists off the Central, it takes forever because it does each one, one at a time. If there's a faster method other than one at a time like that, it would be cool if RioBackup could do that too.

https://rmml.dev.java.net/servlets/ProjectDocumentList?folderID=438

new "wiperestore" instead of "restore" ... you're the first user, so be prepared to reload your central to be sure this is what you want, when you specify wiperestore, it will delete ALL PLAYLISTS from your centrl prior to recreating them.

New version of riobackup.jar worked flawlessly, thanks very much for making that change.