jEmplode + Pearl + Jupiter + Empeg = One Wild Ride
Posted by: mschrag
jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 03/02/2004 12:08
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.
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 03/02/2004 12:39
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.
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 12:49
This post is a great example of why you earned the title FAQ Master
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 12:55
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.
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 13:02
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.
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 13:05
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.
Posted by: Roger
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 13:07
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.
Posted by: Roger
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 13:11
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.
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 13:12
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.
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 14:18
For some reason I cannot download the jemplode.jar file at
http://www.inzyme.com/rio/jemplode.jar 
Sean in NC
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 14:25
Oops .. make that
http://www.inzyme.com/rio/empeg/jemplode.jar ... i'll edit the original post
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 14:29
Gracias...
Posted by: MysticalBS
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 17:30
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???
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 18:02
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).
Posted by: Roger
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 18:13
Note that this requires ethernet
Or HPNA, for which the Central is equipped.
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 18:30
Oh right, duh. I keep forgetting.
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 03/02/2004 21:36
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.
Posted by: LittleBlueThing
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 04/02/2004 04:47
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
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 04/02/2004 07:15
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
Posted by: LittleBlueThing
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 04/02/2004 07:49
'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
Posted by: peter
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 04/02/2004 08:06
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
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 04/02/2004 08:41
I forgot to upload the latest source, so hold off for a bit .. I'll reply when I put it up there.
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 10/02/2004 23:05
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
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 00:43
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.
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 01:15
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
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 01:59
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.
Posted by: msaeger
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 02:09
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 ?
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 02:15
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.
Posted by: peter
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 05:30
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
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 07:23
Good point ... I personally don't have enough to run into this, but there definitely are some folks out there who do.
In reply to:
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.
I considered something similar to this as well. Actually for soups on the Karma I went the route of uploading a .soups file to taxi that contained FID=>soup tag mappings so you could use multiple machines if you wanted. I don't know if Jupiter acknowledges type=taxi, though, so I don't know if I could implement that on all three of them (haven't looked though).
I wonder how many tunes you'd have to have before setting RID directly becomes a problem?
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 11:12
Tony,
Thank you for the great advice.
Sean in NC
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 11:29
No prob.
Posted by: oliver
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 15:01
I'm not sure if I should even comment on the empeg's player software.
But I think it would make alot of sense to select only the ID3 tags that the player actually needs for visual playback to the permanently-resident memory footprint.
It seems like, if you only looked at Track Number, Track Name, Artist, Album, Year, Genera. And set those to the memory footprint, you could save a lot of potential ram for the player to use.
I've always removed the comments fields from all my tracks, just because of this side-effect.
I really don't see why the empeg would cache every ID3 tag into memory. That really seems like alot of overkill.
Anyways, please don’t take this as any major issues, I’m just trying to think of anyway to reduce the amount of ram the player uses on a normal basis.
Posted by: image
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 19:49
its been mentioned before, and it's been proposed that the player will read the actual *1 FID if it gets requested (via the INFO screen). don't really know what became of it. certainly not in the alphas.
Posted by: tonyc
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 11/02/2004 21:01
and it's been proposed that the player will read the actual *1 FID if it gets requested
Yeah, but at the very least the player would have to keep a few tracks ahead (and probably behind) cached up already, because if it didn't, and it goes to read the *1 FID when the disks are spun down, it'll cause a very noticable delay.
Still a good idea, though, as keeping the entire player database in memory is a very large pain for those who want to run user applications in the leftover memory space.
Posted by: Roger
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 12/02/2004 08:52
But I think it would make alot of sense...
We know. They know. This is why Karma uses a different database format, that allows certain fields not to be loaded, plus it's a more compact format anyway.
The plan was (is?) to move over to the Karma format before v3.0-final, whenever that might happen.
Posted by: oliver
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 12/02/2004 20:15
kudos to the empeg guys.
Keep up the awesome work!
Also, I love my karma, it keeps me sane
Posted by: Ezekiel
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 14/02/2004 19:58
Tony,
Right now I'm running RioRID on my newly annointed A3v7 empeg (currently at 199 of 6863 - this should take all night). I have a question - when I'm done running this, I should be able to copy playlists from my wife's Karma directely to my empeg and no music files will have to be transferred beteween the devices, yes? All the music on her Karma is a subset of the music on my empeg.
Conversely, if I copy a playlist from my empeg which contains some songs that are not present on the Karma, what will happen? Will jEmplode copy the songs needed to complete the playlist from empeg --> Karma?
I just want to make sure I'm clear. Thanks.
-Zeke
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 15/02/2004 11:37
Correct on all points, that's the idea with this new Jemplode. Although I have not tried this with the v3 Alpha software, so I don't know if that's a factor.
Note that in order for it to count the songs as the same, the song files themselves have to be identical on both players. You can't have two different rips of the same song and expect them to be counted as identical. Also, I have only tried it with MP3s, so I don't know whether this extends properly to all song file formats.
Posted by: Ezekiel
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 15/02/2004 13:50
Tony,
I'm doing my first playlist copy now (image attached). For everyone's benefit, it's a two step process - copy the playlist and then synchronize. I've attached a screenshot of the first step.
Watching my network traffic meter it seems as if the songs are routed through the PC, but not stored on it (inbound and outbound traffic are equal during the sync stage). Very cool. It's a bit slow over my 802.11b link (empeg side), but it seems to be working fine. I synced a few songs from Karma to empeg last night and that worked great.
Thanks guys!
-Zeke
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 15/02/2004 18:11
In reply to:
it seems as if the songs are routed through the PC, but not stored on it
Yep .. It opens a socket to the source and a socket to the target and copies the data straight from source to target ... The PC is in the middle, so you are right that it's actually source=>PC=>target, but it doesn't write to disk, it goes network all the way through.
ms
Posted by: SE_Sport_Driver
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 16/02/2004 23:21
So the player database IS in memory all the time? Most of my rips have comment tags in them (usually specifying what program I used and version of Lame). This is done out of habit and is of no use to me.. Would it free up memory on my empeg (22,000 songs) if I cleared all my comment fields in emplode/jemplode? Could I just view and select "All Tracks" and clear out the Comment Field to do this?
Posted by: SE_Sport_Driver
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 16/02/2004 23:33
Tony, I think you're onto something with the idea of removing the PC from the loop. You seriously have me considering using a Central for my backup needs rather than trying to keep two foreign devices in sync.
Of course, this would involve either finding a RioCentral and getting it upto 160+GB or hacking my Mk2 "backup" empeg for as a home-only player that used an 3.5" drive (probably beyond my ability?).
One question I have... where is the developement of Jemplode vs. RMML going? I noticed these new tools are available on the RMML developers page, but Jemplode is used to do the actions... Sorry, I've only seen talk of RMML in the Karma threads, so I haven't kept too up to date on it.
Of course, lately I've also been way out in left feild when trying to understand these things, so maybe I don't know what I'm talking about!
Posted by: Micman2b
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 16/02/2004 23:42
Unless something has changed, I have heard there is a 120gb limitation on the Rio Central's 3.5in drive...
Sean in NC
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 17/02/2004 06:25
I originally wrote some of these apps for the Karma, but RMML and jEmplode share like 90% of the same code, and the API's are the same between the two, so anything I write for the Karma can trivially be adapted to add Empeg support as well, so some of the tools got Empeg supported turned on (usually by request of Tony), so I just let them be hosted at RMML's site. That's all there is to that conspiracy
They will proceed along their separate development lines ...
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 17/02/2004 11:27
Tony, I think you're onto something with the idea of removing the PC from the loop. You seriously have me considering using a Central for my backup needs rather than trying to keep two foreign devices in sync.
Well, even I haven't gotten there yet. But I have to say, with the latest Jemplode release and working hierarchical playlists on the Karma and the Central, I'm having trouble coming up with any reason to keep the MP3s on my PC. I think that the latest Jemplode releases, along with the playlist backup utility, removed the last reasons I had for keeping things on the PC.
Oh wait, I can think of one reason, but it's totally unrelated to to the empeg or the Central. With the beta testing I do for the Karma (or any other Rio player for that matter), I often have to wipe the player and reload it from scratch. This goes much faster if I use USB2 and the source is the PC. But for anyone who's not doing that kind of thing, then yeah, having the Central be your Empeg's backup can work.
Posted by: drakino
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 21/02/2004 16:20
Just tried some empeg v2 -> Karma syncing this past weekend and it seemed to work decently if I did the copy/paste procedure in small bits. But, trying to do a major portion of my empeg lead to an eventual slowdown of jEmplode with the Java process on my Windows XP box (JVM 1.41 or 1.42, will double check for sure when I get home) taking 100% of the time. Slow as in 2-3 minutes to read the track info from the empeg after 8 hours of letting it run, compared to the track every second or two when it started.
I'll probably try a mass paste on my Powerbook instead to see if it is a JVM issue on Windows.
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 21/02/2004 16:23
Very weird ... I"ll play around with it and see if I can tell what's going on.
Posted by: tfabris
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 22/02/2004 00:30
Mike, I seem to recall seeing something similar to what Tom describes when I was playing with it. Remember we talked about it in chat?
Posted by: drakino
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 22/02/2004 11:14
It is indeed JVM 1.4.2 I have on the Windows box. I also was doing a sync last night of two of my master playlists from the empeg, and this morning it failed with I believe "Unable to communicate with device". The Transfer window showed the tracks that had been sent over, and the ones pending, but nothing would get it to go again. The Karma was still on the sync screen. Wish I had more info, I had to rush off to work though.
I'll be trying the bigger syncs off the Powerbook probably tomorrow night.
Posted by: jmullan
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 27/02/2004 10:38
My Karma locks up during transfers routinely. At first I thought that it was because I was using jEmplode, but I have now had it lock up while transferring from RMM. I deleted everything off of my Karma and resynced with RMM and the frequency of lockups went down by a lot, but it still happens from time to time.
Posted by: mschrag
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 27/02/2004 11:05
Did you resync with RMM w/ Ethernet and what firmware?
Posted by: jmullan
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 27/02/2004 15:54
Yep, I gave up on USB2 since my Karma never liked it. I use ethernet and firmware 1.41.
I've just been really busy, so I haven't been able to do rigorous testing, and I didn't want to complain or file a bug without being able to come up with consistent scenarios. Well, besides "if I try to change standard or custom fields with jEmplode" or "if I mess around too much with soups on my Karma."
I deleted everything off of my Karma and resynced only with RMM, which seemed to fix everything, until a week or so ago when one particular file caused things to lock up. Since then, now and then my Karma gets mad at me and requires a reset.
I had been playing with jEmplode (you've heard me talk about it before), but I couldn't get a handle on what specific actions were causing the lockups, so I was trying to go back to a known state to resume testing - thus reverting to RMM.
I wish that I could give you something more useful to work on, but that's it. Sometimes my Karma just hangs in "communicating" mode without communicating.
Posted by: drakino
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride - 05/03/2004 12:41
Ok, playing with this on my Powerbook is even worse. If jEmplode starts to open the empeg, the CPU is pegged at 100%. Once the databases get downloaded, it stays at 100%, and the interface is horribly slow. Opening the Karma on the Powerbook does not result in such CPU spikes.
This is using Panther, 10.3.2 and Java:
814:drakino:~>java -version
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-117.1)
Java HotSpot(TM) Client VM (build 1.4.2-34, mixed mode)
And jEmplode v54
Another bug I forgot to report. If I open my empeg first, select another device sees the empeg again and the Karma. But, if I open the Karma first, then select another device, the empeg never shows up, even if I put the IP in the specific device option.
Posted by: adavidw
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 08/03/2004 03:47
Mike,
In reading around on Riovolution, I saw where Peter had mentioned that RMM changed it's way of calculating RIDs for Vorbis files from 2.4 to 2.6. Basically, in 2.6 it ignores the vorbis comment blocks, and before it didn't. How does jemplode do it? Will it correctly see a file put on the Karma post 2.6 as a duplicate or not? Also, does the algorithm that calculates RIDs for other files ignore the tags for those files?
Posted by: peter
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 08/03/2004 03:58
In reading around on Riovolution, I saw where Peter had mentioned that RMM changed it's way of calculating RIDs for Vorbis files from 2.4 to 2.6. Basically, in 2.6 it ignores the vorbis comment blocks, and before it didn't. How does jemplode do it? Will it correctly see a file put on the Karma post 2.6 as a duplicate or not? Also, does the algorithm that calculates RIDs for other files ignore the tags for those files?
RMML currently disagrees with 2.6, which is my fault for being really slack about providing Mike with the new algorithm.
In RMM 2.6 the algorithms for all filetypes ignore tags, except that the Flac one doesn't ignore Flac tags (it does ignore ID3v2 tags, which is all RMM 2.6 knows how to write to Flac files). A future RMM will both rewrite real Flac tags and ignore them when calculating RID.
Peter
Posted by: adavidw
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 08/03/2004 04:19
Thanks Peter,
Did anything else change in the RID calculation from 2.4 to 2.6? In other words, were all the other formats tag-independent already? In other other words, will RMML and its related utilities agree with RMM on the other formats?
Posted by: peter
Re: jEmplode + Pearl + Jupiter + Empeg = One Wild - 08/03/2004 04:24
In other other words, will RMML and its related utilities agree with RMM on the other formats?
Yes.
Peter