Unoffical empeg BBS

Quick Links: Empeg FAQ | RioCar.Org | Hijack | BigDisk Builder | jEmplode | emphatic
Repairs: Repairs

Page 1 of 2 1 2 >
Topic Options
#202214 - 03/02/2004 12:08 jEmplode + Pearl + Jupiter + Empeg = One Wild Ride
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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.


Edited by mschrag (03/02/2004 14:25)

Top
#202215 - 03/02/2004 12:39 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride [Re: mschrag]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202216 - 03/02/2004 12:49 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
This post is a great example of why you earned the title FAQ Master

Top
#202217 - 03/02/2004 12:55 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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.

Top
#202218 - 03/02/2004 13:02 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202219 - 03/02/2004 13:05 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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.

Top
#202220 - 03/02/2004 13:07 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5680
Loc: London, UK
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.
_________________________
-- roger

Top
#202221 - 03/02/2004 13:11 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5680
Loc: London, UK
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.
_________________________
-- roger

Top
#202222 - 03/02/2004 13:12 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202223 - 03/02/2004 13:13 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Roger]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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...
_________________________
Tony Fabris

Top
#202224 - 03/02/2004 14:18 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
For some reason I cannot download the jemplode.jar file at http://www.inzyme.com/rio/jemplode.jar

Sean in NC
_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202225 - 03/02/2004 14:25 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Micman2b]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Oops .. make that http://www.inzyme.com/rio/empeg/jemplode.jar ... i'll edit the original post

Top
#202226 - 03/02/2004 14:29 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
Gracias...
_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202227 - 03/02/2004 17:30 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
MysticalBS
new poster

Registered: 01/02/2004
Posts: 3
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???

Top
#202228 - 03/02/2004 18:02 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: MysticalBS]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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).
_________________________
Tony Fabris

Top
#202229 - 03/02/2004 18:13 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5680
Loc: London, UK
Note that this requires ethernet

Or HPNA, for which the Central is equipped.
_________________________
-- roger

Top
#202230 - 03/02/2004 18:30 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Roger]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
Oh right, duh. I keep forgetting.
_________________________
Tony Fabris

Top
#202231 - 03/02/2004 21:36 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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.

Top
#202232 - 04/02/2004 04:47 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
LittleBlueThing
addict

Registered: 11/01/2002
Posts: 612
Loc: Reading, UK
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
_________________________
LittleBlueThing Running twin 30's

Top
#202233 - 04/02/2004 07:15 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: LittleBlueThing]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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

Top
#202234 - 04/02/2004 07:49 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
LittleBlueThing
addict

Registered: 11/01/2002
Posts: 612
Loc: Reading, UK
'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
_________________________
LittleBlueThing Running twin 30's

Top
#202235 - 04/02/2004 08:06 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Roger]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
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

Top
#202236 - 04/02/2004 08:41 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: LittleBlueThing]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
I forgot to upload the latest source, so hold off for a bit .. I'll reply when I put it up there.

Top
#202237 - 10/02/2004 23:05 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
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
_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202238 - 11/02/2004 00:43 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Micman2b]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202239 - 11/02/2004 01:15 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
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

_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202240 - 11/02/2004 01:59 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Micman2b]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202241 - 11/02/2004 02:09 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
msaeger
carpal tunnel

Registered: 23/09/2000
Posts: 3608
Loc: Minnetonka, MN
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 ?
_________________________

Matt

Top
#202242 - 11/02/2004 02:15 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: msaeger]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202243 - 11/02/2004 05:30 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
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


Edited by peter (11/02/2004 05:38)

Top
#202244 - 11/02/2004 07:23 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: peter]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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?

Top
#202245 - 11/02/2004 11:12 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
Tony,
Thank you for the great advice.

Sean in NC
_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202246 - 11/02/2004 11:29 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Micman2b]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
No prob.
_________________________
Tony Fabris

Top
#202247 - 11/02/2004 15:01 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: peter]
oliver
addict

Registered: 02/04/2002
Posts: 691
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.
_________________________
Oliver mk1 30gb: 129 | mk2a 30gb: 040104126

Top
#202248 - 11/02/2004 19:49 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: oliver]
image
old hand

Registered: 28/04/2002
Posts: 770
Loc: Los Angeles, CA
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.

Top
#202249 - 11/02/2004 21:01 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: image]
tonyc
carpal tunnel

Registered: 27/06/1999
Posts: 7058
Loc: Pittsburgh, PA
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.
_________________________
- Tony C
my empeg stuff

Top
#202250 - 12/02/2004 08:52 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: oliver]
Roger
carpal tunnel

Registered: 18/01/2000
Posts: 5680
Loc: London, UK
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.
_________________________
-- roger

Top
#202251 - 12/02/2004 20:15 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Roger]
oliver
addict

Registered: 02/04/2002
Posts: 691
kudos to the empeg guys.

Keep up the awesome work!

Also, I love my karma, it keeps me sane
_________________________
Oliver mk1 30gb: 129 | mk2a 30gb: 040104126

Top
#202252 - 14/02/2004 19:58 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Ezekiel
pooh-bah

Registered: 25/08/2000
Posts: 2413
Loc: NH USA
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
_________________________
WWFSMD?

Top
#202253 - 15/02/2004 11:37 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Ezekiel]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202254 - 15/02/2004 13:50 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
Ezekiel
pooh-bah

Registered: 25/08/2000
Posts: 2413
Loc: NH USA
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


Attachments
203440-jEmplode-Screenshot.jpg (256 downloads)

_________________________
WWFSMD?

Top
#202255 - 15/02/2004 18:11 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: Ezekiel]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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

Top
#202256 - 16/02/2004 23:21 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tonyc]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
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?
_________________________
Brad B.

Top
#202257 - 16/02/2004 23:33 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: tfabris]
SE_Sport_Driver
carpal tunnel

Registered: 05/01/2001
Posts: 4903
Loc: Detroit, MI USA
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!
_________________________
Brad B.

Top
#202258 - 16/02/2004 23:42 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: SE_Sport_Driver]
Micman2b
addict

Registered: 27/12/2001
Posts: 441
Loc: Central, NC, USA
Unless something has changed, I have heard there is a 120gb limitation on the Rio Central's 3.5in drive...


Sean in NC
_________________________
_____________
Sean in NC
130gb MK2a w/ 32mb ram
80gb MK2a empeg spare

Top
#202259 - 17/02/2004 06:25 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: SE_Sport_Driver]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
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 ...

Top
#202260 - 17/02/2004 11:27 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: SE_Sport_Driver]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#202261 - 21/02/2004 16:20 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride [Re: mschrag]
drakino
carpal tunnel

Registered: 08/06/1999
Posts: 7868
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.

Top
#202262 - 21/02/2004 16:23 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: drakino]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Very weird ... I"ll play around with it and see if I can tell what's going on.

Top
#202263 - 22/02/2004 00:30 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 31565
Loc: Seattle, WA
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?
_________________________
Tony Fabris

Top
#202264 - 22/02/2004 11:14 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride [Re: drakino]
drakino
carpal tunnel

Registered: 08/06/1999
Posts: 7868
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.

Top
#202265 - 27/02/2004 10:38 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride [Re: drakino]
jmullan
new poster

Registered: 08/01/2004
Posts: 13
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.

Top
#202266 - 27/02/2004 11:05 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: jmullan]
mschrag
pooh-bah

Registered: 09/09/2000
Posts: 2303
Loc: Richmond, VA
Did you resync with RMM w/ Ethernet and what firmware?

Top
#202267 - 27/02/2004 15:54 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
jmullan
new poster

Registered: 08/01/2004
Posts: 13
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.

Top
#202268 - 05/03/2004 12:41 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild Ride [Re: drakino]
drakino
carpal tunnel

Registered: 08/06/1999
Posts: 7868
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.

Top
#202269 - 08/03/2004 03:47 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: mschrag]
adavidw
addict

Registered: 10/11/2000
Posts: 497
Loc: Utah, USA
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?
_________________________
-Aaron

Top
#202270 - 08/03/2004 03:58 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: adavidw]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
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

Top
#202271 - 08/03/2004 04:19 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: peter]
adavidw
addict

Registered: 10/11/2000
Posts: 497
Loc: Utah, USA
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?
_________________________
-Aaron

Top
#202272 - 08/03/2004 04:24 Re: jEmplode + Pearl + Jupiter + Empeg = One Wild [Re: adavidw]
peter
carpal tunnel

Registered: 13/07/2000
Posts: 4172
Loc: Cambridge, England
In other other words, will RMML and its related utilities agree with RMM on the other formats?
Yes.

Peter

Top
Page 1 of 2 1 2 >