After the donation of a Jupiter by the Pearl beta manager and some prodding by Tony, I finally got jEmplode working properly with it. Then after Tony shared his dream of being able to copy and paste from his Jupiter to his Empeg to his Karma, I thought I'd see what it would take to do. Turns out not much. So I put up a new jar ( http://www.inzyme.com/rio/empeg/jemplode.jar ) that has support for all three.

There is a new item under the File menu "Open New Device ..." that will let you open a second (or third) window. The devices all share a common clipboard, so you can copy-and-paste between them. No drag-n-drop yet, but someone submitted a patch for that a while back and I just haven't integrated it yet because I was afraid of impacting RMML.

The one catch here is that for uniquing to work properly, all your tunes need RID's. if you are using 2.x on your Empeg, you probably don't have them, but you can get RioRID from http://rmml.dev.java.net (in the Other Karma Apps section) and it will recompute RID's for all your tunes. This may take a while (it's basically doing the process that occurs on import into jEmplode, but downloading off the player instead of reading from the filesystem).

For Jupiters, there's a bit of a catch. Not only does Jupiter not get RID's calculated, it turns out it's not possible (currently) to even set a tag named RID. So for the Jupiter, when you run RioRID (just use "empeg" as the commandline param -- they are the same protocol), it will piggyback on your comments fields. So if you had a comment like "I am in love with Mike", that would become "I am in love with Mike;RID=xxxxxxxxxx".

RioBackup is another one of the apps at rmml.dev.java.net that is compatible with the Empeg and Karma, so you can use that as well. To run any of the rmml apps, you will want to put the jars in the same folder as jemplode.jar. Most of the RMML apps are commandline only, so you'll want to run them as "java -jar riorid.jar" in a shell.

Another cool thing that Tony told me is that Jupiter supports hierarchical playlists just like Karma does (that is, it supports them secretly ), so you should be able to copy all of your nested playlists around happily.

Anyway, enjoy .. I have no idea what version number I put on jEmplode this time. As always, this is alpha/beta/whatever -- If your wife or husband leaves you and takes your Jupiter with you because of something jEmplode did, I'm not responsible.

ms

P.S. the source that's up there doesn't match ... I'll upload that when I get home.

I'd like to clarify a few of Mike's points for everyone...

1. The whole point of the RIDs:

If you copy a playlist from one device to another, how does it know if the song is already on the destination player or not?

Ideally, you would want to be able to copy a playlist from the Empeg to the Karma so that if a given tune was already on the Karma, it would only copy the playlist entry. But if the tune wasn't already on the Karma, then it would copy both the tune and the playlist entry.

How does it know if the tune is on there? That's the RID. It's calculated purely based on the audio data in the file. It's a unique ID number that tells one tune from the next without having to do a time-consuming file comparison.

2. The reason the RIDs sometimes need to be recomputed:

Because the Empeg, Emplode, and the Rio Central don't calculate them. It's a new thing they invented with the Karma. I *think* that RMM calculates them when you send tunes to the Karma, and I'm sure that the recent releases of Jemplode calculate them when sending to all three devices. It's only when you're dealing with tunes ripped on the Central, or tunes uploaded to any device with Emplode, that it becomes an issue.

3. What I did with this:

I have all the same tunes on my Central, my Empeg, and my PC's hard disk. I have a subset of those tunes on the Karma. But I still want all my custom playlists to be the same on all the devices.

Before, I had to copy tunes to the devices, then painstakingly hand-create the custom playlists on each device.

Last night, I did this:

Made sure that the new Jemplode.jar, riorid.jar, and riobackup.jar were all in the same folder on the hard disk.

Made sure my empeg (.130) had rids by doing this:
java -jar riorid.jar empeg 192.168.0.130 " " missing
(the " " is because I have no password on the empeg)

Made sure my Central (.4) had rids by doing this:
java -jar riorid.jar empeg 192.168.0.4 " " missing

Made a backup of all the playlists from the empeg, into a file named "backup.empeg" by doing this:
java -jar riobackup.jar empeg 192.168.0.130 "" backup backup.empeg

Removed all playlists from the Central in Emplode (or Jemplode would have worked). Did not remove the tunes, just the playlists.

Restored the empeg's playlists onto the Central by doing this:
java -jar riobackup.jar empeg 192.168.0.4 "" restore backup.empeg

After it was all done, the extensive playlist tree from the empeg is now working on the Central. It also works on the Rio Receiver that is slaved to the Central. All the menus seem to work, I can navigate to individual tree branches and play them, or play the top level playlist tree or whatever. It all seems to work.

Note that I could have also done this backup/restore operation with a much simpler copy/paste in Jemplode, but this way is faster because it doesn't need to individually-process each song as part of the copy/paste.

4. One issue with the Central:

If you do copy hierarchical playlists over to the Central, or create them on the Central using Jemplode, then you're stuck using Jemplode after that. Because Emplode assumes the Central has flat playlists, and you get Little Red Boo Boo Icons (tm) on all the hierarchical playlists.

This post is a great example of why you earned the title FAQ Master

In reply to:

---

I *think* that RMM calculates them when you send tunes to the Karma

---

Yep.

jEmplode has been using the same algorithm for computing RID's for a while. Roger sent me the rules for it many moons ago. I haven't checked to see if the Emplode that matches the Empeg 3.0 versions compute RID -- they might.

In reply to:

---

then you're stuck using Jemplode after that

---

Just to clarify -- You're not necessarily stuck using jEmplode, but as long as you want to preserve your hierarchical playlists, you must use jEmplode. Just want to make it clear that you /can/ go back to using Emplode at any time, but it will just "fix" your playlists.

but it will just "fix" your playlists.

I'm afraid to see exactly how it would fix them. The sub-entries aren't visible, so I'm afraid it would delete them instead of flatten them. If it just flattened them, that would be cool with me.

Yeah -- I can't vouch for that The standard form for dealing with orphaned playlists is to attach them to the Root as a top level playlist, but you would have seen that in Emplode. If that's not happening, then all bets are off as to what exactly it /will/ do.

if the Emplode that matches the Empeg 3.0 versions compute RID -- they might.

Unlikely. I don't think any changes have been made to emplode beyond the minimum required to get it to upload Ogg and FLAC files.

Future plans were (when I left) to make the empeg use the same protocol and database as Karma and to add hierarchical playlists to RMM.

The standard form for dealing with orphaned playlists is to attach them to the Root

The playlist "fixing" code in emplode, when shown a Central, will do basically what Mike describes: playlists that aren't directly attached to the root (whether orphaned or not) are reattached to the root. This isn't the same as flattening them.

Tunes that aren't attached to any playlists are left alone -- they don't have to be attached on Central.

Tunes that are in the root playlist are detached and left orphaned.

Basically, the invariant is that you can only have playlists at the root, and that they can only contain tunes.

If you ask nicely, Peter might be able to make the next alpha release of emplode not do this to Centrals -- it's just a flag in one of the header files in lib/model.

The standard form for dealing with orphaned playlists is to attach them to the Root as a top level playlist, but you would have seen that in Emplode.

Hmmm, perhaps it did precisely that. That would make sense. I seem to recall something to that effect. I don't recall exactly, I just remember thinking it looked like a mess in Emplode, but just fine in Jemplode. Since I expected it to be a mess in Emplode, I didn't really look closely at the nature of the mess other than to see that it didn't support the hierarchy.

If you ask nicely, Peter might be able to make the next alpha release of emplode not do this to Centrals -- it's just a flag in one of the header files in lib/model.

I was wondering if it was a simple flag or not.

Hey, Peter...

For some reason I cannot download the jemplode.jar file at http://www.inzyme.com/rio/jemplode.jar

Sean in NC

Oops .. make that http://www.inzyme.com/rio/empeg/jemplode.jar ... i'll edit the original post

Gracias...

I was thikin about getting a Central from overstock.com. I have a few questions after doing some reaserch about the Central. There is no keyboard but you can add one via the USB port right?

In reply to:

---

Made sure my Central (.4) had rids by doing this:
java -jar riorid.jar empeg 192.168.0.4 " " missing

---

How do you enter this into the central? Do you plug in a keybaord and access the central from there to type this in??? Or do you access via a terminal window???

There is no keyboard but you can add one via the USB port right?

Correct.

How do you enter this into the central?

You don't. That's a the DOS command line on a PC with the latest Sun Java Runtime engine. Note that this requires ethernet, which is not built-in to the Central (it requires one of the few compatible USB-to-Ethernet adapters for that).

Note that this requires ethernet

Or HPNA, for which the Central is equipped.

Oh right, duh. I keep forgetting.

And actually I have the latest USB driver DLL for Empeg/Central for jEmplode, but it's kind of flaky. If someone needs this as a last resort, just PM me.

In reply to:

---

No drag-n-drop yet, but someone submitted a patch for that a while back and I just haven't integrated it yet because I was afraid of impacting RMML.

---

That was me
(Been busy with work, teaching the other half to ski, and starting running - terrible excuses for not keeping up but there you are)

And it was a fairly intrusive patch and I dont know if you'll like the approach I took. If you want to comment on any of it I'll see if I can rework any areas that you're not happy with.

I'll also try and make it apply cleanly against your latest source - ping me if there is a later package. (OTOH if you're already into this work then I'll leave you to it )

David

Actually I don't know that anything that you patched against has really changed that much, so it will probably apply pretty cleanly ... My concern isn't a comment on your code as much as it is just a large patch (by nature), and I have been too lazy to go through and review it all to see if there are any wacky side effects on the RMML side (which you don't have source to, so couldn't anticipate). Hope you haven't taken offense to me dissing you patch for a while now

'course not - I'm hard to offend

probably because if someone's taken the time and effort to criticise code etc then I'm more than happy to listen and learn ('course in some cases I may be learning about code - in others I'm learning about the person )

In reply to:

---

so it will probably apply pretty cleanly

---

I'll see if I can try it tonight to check...

David

If you ask nicely, Peter might be able to make the next alpha release of emplode not do this to Centrals -- it's just a flag in one of the header files in lib/model.

I couldn't possibly cvs commit, I mean comment.

Peter

I forgot to upload the latest source, so hold off for a bit .. I'll reply when I put it up there.

Is there any way to add RID's to the hard disk on the computer using riorid.jar? It would be nice to have them there also.

Also, slight confusion here, So, the files on the empeg and the karma have RID's, after creation, and therefore you can check to see if the file already exists. What is the benefit for the Central to have these in the comment field, is it there just for the riorbackup.jar to use to know where to place the file into the correct playlists? Also, does jEmplode place the RID in the comment field on the empeg's files so you do not have to rerun riorid.jar each time you add music?

So many questions, so little time...

Sean in NC

Is there any way to add RID's to the hard disk on the computer using riorid.jar?

Not at the current time. It only writes to the player databases, not to the tags on the files themselves.

What is the benefit for the Central to have these in the comment field

Because of a limitation in the code of the Central that prevents the creation of the "RID" field in the Central's database, the comment field is the only remaining field in which he can put the data in that particular case.

is it there just for the riorbackup.jar to use to know where to place the file into the correct playlists?

It's there for whenever Jemplode or Riobackup needs to find out if a file is a duplicate, or to definitively identify/locate a specific song regardless of how it's tagged.

Example 1:
- I run Jemplode.
- In Jemplode I open the Central and then also open the Empeg.
- I copy playlists back and forth between the two devices.
- Rids are used to decide whether just the playlist entry needs to be copied, or if it needs to copy the song file, too.

Example 2:
- I have all the song files on both devices.
- I back up all the playlists from one device.
- I restore the playlists onto the other device.
- Rids are used to match up which songs go with which playlist entry.

Also, does jEmplode place the RID in the comment field on the empeg's files so you do not have to rerun riorid.jar each time you add music?

No, the music files and their tags are not touched. Remember, we are only working with the player databases, not the MP3 files or their tags.

In reply to:

---

Remember, we are only working with the player databases, not the MP3 files or their tags.

---

This answers most of my questions except for two nagging issue i cannot grasp.

Tony, you said you have files on your empeg, files on your central and files on your hard drive that are all synced. OK, so I copy a CD with the Central, there are no RID's in the Central's database at this point. So, to get RID's added the empeg database I would move the files via Jemplode so it would add the RID's on download from the Central?

But the Central has no RID field in the comments at this point. I guess that you have to rerun riorid.jar each time you add files to the Central?

After these files are coded in the database properly then you place the files on the hard drive manually using the same directory tree.

When you had a file on the hard drive that you wanted moved over to the empeg and Central, you would copy first to the files to the empeg via jEmplode therefore adding RID's then copy the file to the Central then run riorid.jar to get the RID's synced?

In reply to:

---

Example 1:
- I run Jemplode.
- In Jemplode I open the Central and then also open the Empeg.
- I copy playlists back and forth between the two devices.
- Rids are used to decide whether just the playlist entry needs to be copied, or if it needs to copy the song file, too.

---

Are you deciding if the playlist entry needs to be copied manually by looking at the database fields when copying files from the empeg to the Central?

Sorry for all the questions but I really like the ability of syncing all my devices, just want to know how...
Sean in NC

OK, so I copy a CD with the Central, there are no RID's in the Central's database at this point.

For that particular CD you just ripped, that is correct.

But the Central has no RID field in the comments at this point. I guess that you have to rerun riorid.jar each time you add files to the Central?

Not each time. Only when I feel like synching stuff up between my multiple devices. But yeah. I've set it up so it's just an icon I double-click on, and it only does it for files missing RIDs so it goes quick.

After these files are coded in the database properly then you place the files on the hard drive manually using the same directory tree.

I can. Actually, now that I've got full playlist synchronization and full copy/paste between devices, I'm seriously considering removing the PC's hard disk from the loop altogether.

When you had a file on the hard drive that you wanted moved over to the empeg and Central, you would copy first to the files to the empeg via jEmplode therefore adding RID's then copy the file to the Central then run riorid.jar to get the RID's synced?

Or I could use Jemplode for all of those operations since it calculates the RIDs on the fly, therefore being able to skip running riorid.jar. The only time I really need to run riorid is if I'm first populating a device with RIDs or if I ripped the CD on the Central which doesn't calculate the RIDs.

Are you deciding if the playlist entry needs to be copied manually by looking at the database fields when copying files from the empeg to the Central?

Of course not. The whole point of the RIDs is so that Jemplode can do that hard work for me. I go to the Central and select <playlistname> and hit <copy>, then I go to the Empeg and hit <parent-playlistname> and hit <paste>, then Jemplode does the rest.

Thanks Mike for taking the time to mess with this I haven't tried it yet though .

If all I want to do is copy files off the central to the empeg and not playlists do I need to worry about the RID's ?

If all I want to do is copy files off the central to the empeg and not playlists do I need to worry about the RID's ?

I don't think so. However, it might be a tad slower to do it that way, since it will try to calculate RIDs on the fly anyway.

The one catch here is that for uniquing to work properly, all your tunes need RID's. if you are using 2.x on your Empeg, you probably don't have them, but you can get RioRID from http://rmml.dev.java.net (in the Other Karma Apps section) and it will recompute RID's for all your tunes. This may take a while (it's basically doing the process that occurs on import into jEmplode, but downloading off the player instead of reading from the filesystem).

One problem with using RioRID, that nobody's mentioned AFAICS, is that it adds a RID value to the database for everything on your player -- that's 33 bytes of permanently-resident memory per track. If you've got lots of songs on a Mark 2, that might add up to enough to push you over the limit into an un-loadable or un-rebuildable database, especially if you're using any of the player v3 alphas.

Edit: If you wanted to obviate that, one way would be to keep a map on the PC of (player serialno, FID) -> (ctime, RID) so you knew when your cached RID was valid and when it wasn't.

Peter