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?

Tony,
Thank you for the great advice.

Sean in NC

No prob.

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.

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.

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.

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.

kudos to the empeg guys.

Keep up the awesome work!

Also, I love my karma, it keeps me sane

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

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,

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

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

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?

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!

Unless something has changed, I have heard there is a 120gb limitation on the Rio Central's 3.5in drive...


Sean in NC

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 ...

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.

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.

Very weird ... I"ll play around with it and see if I can tell what's going on.

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?

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.

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.

Did you resync with RMM w/ Ethernet and what firmware?

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.

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.

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?

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

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?

In other other words, will RMML and its related utilities agree with RMM on the other formats?

Yes.

Peter