OK this is a small thing, but I went ahead and uploaded it this morning ... I added a workaround for supporting jEmplode's custom soups on the Karma (so they continue to update). If you use this feature, temporarily, you'll want to let your transfers complete all the way through (the soup file isn't written until the very end) otherwise your soups won't be very soupy any longer. Shout outs to Cliff Biffle from the Karma board for the idea of the workaround.

ms

Is the "fast database rebuild" feature intended to be useable with v2final?

thanks

nope, though the actual format of the files has not changed ... I don't have 2.0 installed anymore, is /empeg/var/database3 called database3 in 2.0, or is the 3 indicitive of 3.0? If it's called 3 in 2 , then it should work. Otherwise I just need to add in a version check.

ms

is the 3 indicitive of 3.0?

The 3 is indicative of 3.0; specifically, it's indicative of UTF-8 rather than ISO-8859-1 tags.

Peter

Yeah, what he said!

On 2.0, the file I see is called "database", with no numeric suffix.

Cheers

it's indicative of UTF-8 rather than ISO-8859-1 tags.

Errr...does this mean we may have the ability to use japanese for tagging in the (near) future? Dare I hope?

aha .. which I believe I don't properly handle in jEmplode .. I'm guessing I'm still ISO-8859-1 for everything.

I downloaded the jar file earlier, but I was having the same java issues crazymelki was having in the other post, I tried messing around with it (specifying the application path for the rebuild command) to no avail. I really would like to use it to try and get v3 alpha 5 on there... just out of curiosity is there going to be an installer for us not so java savy people?

Can you post the exception? I modified it a little in 49 so it prints the FTP error code too, so maybe I can figure out why it's failing.

So what kernel version are you running on there now?

The installers are like 23M, and with my lame upload speed w/ my satellite connection, I try to be damn sure I don't have to upload them twice I'm hoping for probably a build 52 or 53 with installers -- maybe by the end of the weekend .. It depends on how sinister the problem is that you guys are seeing with rebuild.

ms

a spell check on my "indicitive" would have gone a long way, huh

this is what it gives me in the details section of the error window.

java.lang.ClassNotFoundException: org.jempeg.empeg.emplode.Main

at java.net.URLClassLoader$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(Unknown Source)

at java.lang.ClassLoader.loadClass(Unknown Source)

at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)

at java.lang.ClassLoader.loadClass(Unknown Source)

at java.lang.ClassLoader.loadClassInternal(Unknown Source)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Unknown Source)

at com.zerog.lax.LAX.launch(Unknown Source)

at com.zerog.lax.LAX.main(Unknown Source)

I'm almost positive it has something to do with my configuration and the fact that I've always been a bit brainless when tweaking java apps, as far as the software version of the empeg I have updated it yet, I was simply trying to get jemplode first.

My guess is that you have a really old jEmplode installer and you just replaced jemplode.jar, right? I'm pretty sure the Main class has changed to another package ... To fix that, edit jEmplode.lax in your installer directory and search for "org.jempeg.empeg.emplode.Main" and change it to "org.jempeg.empeg.manager.Main" (I think that's the package it's in now). alternatively you can just run jEmplode by double-clicking on jemplode.jar or running it "java -jar jemplode.jar" from the commandline.

ms

ok when I replace that line in the jemplode.lax, I get the same error. When I double click the jar file I get "Could not find the main class, program will exit", and from command line I get "exeption in thread "main" java.util.zip.ZipException: The system cannot fine the fild specified
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)
at java.util.zip.ZipFile.<init>(Unknown Source)

Dunno, is my install whacked or what?

Go to a commandline and run java -fullversion and post what that spits back ...

java full version "1.4.2_03-b02"

Yeah that should work ... You'd also get that error if you didn't fully download the jar file. Here's the md5sum:

e81d2d581ecff17c6910db45d91e9b26 *jemplode.jar

and it should be 3,245,561 bytes. Might want to redownload it ...

That was it... pretty doggie... thats weird, I was using getright and everything. Thanks!

The only reason I found that out is that I tried to run mine before the download was finished ... pretty lame ass error handling on java's part. A little checksumming would go a long way.

aaarrrggg.... so I get my empeg updated to v3 alpha 5, I execute "java -classpath jemplode.jar org.jempeg.empeg.protocol.RebuildDatabase 192.190.1.131" and I get "Exception in thread "main" java.lang.NoClassDefFoundError: org/jempeg/empeg/protocol/RebuildDatabase" any ideas?

Ok, after I got that error, I navigated to the lib directory where jemplode.jar lives, do the same command and I get a different error, this one starts goes like this.

C:\Program Files\jEmplode\lib>java -classpath jemplode.jar org.jempeg.empeg.prot
ocol.RebuildDatabase 192.190.1.131
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at com.enterprisedt.net.ftp.FTPControlSocket.<init>(FTPControlSocket.jav
a:157)
at com.enterprisedt.net.ftp.FTPControlSocket.<init>(FTPControlSocket.jav
a:145)
at com.enterprisedt.net.ftp.FTPClient.<init>(FTPClient.java:161)
at org.jempeg.empeg.protocol.RebuildDatabase.main(RebuildDatabase.java:3
1)

C:\Program Files\jEmplode\lib>

go back to 2

It's either still not properly downloaded or you have the wrong version. If you got it from http://www.inzyme.com/rio/empeg/jemplode.jar and it's doing that then there's something wrong with your download. I would probably recommend just waiting until the full installers come out.

That would be too easy... Actually I think I did something silly, I forgot to put the lates hijack on.... did they put illuminated button support in the new build??

I just saw there was an edit on the original email. You don't have hijack installed.

Yeah... sorry, it threw me when I put v3 alpha 5 and my buttons were glowing. Once again I apologize guys, but thanks for all the help!

I don't think the font file has the character images needed to display that. It's making the font that is the hard part, you're very limited on screen real estate for each character.

you're very limited on screen real estate for each character.

Very true. There is, however, the Elisa 8x8 Kanji Font. I use it on my Palm (which serves as my dictionary) and it's actually quite legible...

Is there any way this could be used to give the empeg CJK tag capability? Assuming Emplode / JEmplode supported UTF-8?

In reply to:

---

Assuming Emplode / JEmplode supported UTF-8?

---

jEmplode needs to be updated, but all the hard work was done for this for the Karma ...

Very true. There is, however, the Elisa 8x8 Kanji Font. I use it on my Palm (which serves as my dictionary) and it's actually quite legible...

That's fine for the big font. The small font is only 6 pixels high. Plus, a Kanji font is huge in terms of memory requirements -- at Amersfoort 2002 I had a car-player with a Kanji font (though nobody really noticed) and it was a 16Mb Mark 2a, because I couldn't fit it in a 12Mb Mark 2.

Peter

Sorry to keep having issues, one last question, I rebuilt the database twice now, the first time when the rebuild finished I rebooted the player and still nothing in the playlist. The second time I rebuilt the database I immediately opened jemplode and still no playlists. Is there anything special I need to be doing after the rebuild?

Someone else has a similar problem, so I'm guessing there's a bug. I'm trying to figure out what is causing it fail for some people.

Great I was affraid of that, I actually rebuilt my disks for v3 alpha 3, that was a pain. I guess I'll just go back to 2, thanks for all the help though Mike.

I had a car-player with a Kanji font

So how much blood, favors, fine imported cigars, etc. would it take....?

This someone has a name........xxxxxmelki

bye

Ouch, after reverting back to 2.0, it still doesn't recognize my databse, tried the database rebuild procedure in the FAQ with no success.

"it" being jEmplode? Make sure you turn off fast database rebuilds in the options ... Then I would ftp in and delete /empeg/var/database3,tags, and playlists and let the player rebuild them.

Here's a basic (J)Emplode newbie question:

My tunes are tagged on my PC with the track numbers included in the tracknames for whatever reason. Eg. "01 - first track". How do I tell JEmplode to strip the tracknumbers off when creating the tags for the player, so that my tunes simply show up as "first track" rather than "01 - first track" in the playlists??

-ml

I don't think Jemplode offers that capability. I think it will take the track tags as-is.

If you don't want the track name to show up like that, then don't name your tracks that way.

You know, they actually have a specific field in the ID3 tag specification just for the track number...

Yes, I noticed that. But RMM wrote them that way, so..

Oh well, back to my Linux script method of uploads again.

Cheers

This was my first reaction to the question also ... So in the ID3 tags they have track number? Who does this? So is this a reallly common problem? If so, I can strip off anything before the first hyphen or something .... I'd prefer not, though, just because it might screw people who actually have hyphens in names.

So is this a reallly common problem?

I've never seen it happen except when a person deliberately names their tracks that way.

I'm surprised to hear Mark say that RMM did it. If so, I'd consider that a bug.

Oh -- I misread his message -- I thought he was saying RMM read them that way (meaning it allowed track numbers in the title)... He's saying RMM WROTE them that way. Yeah that definitely seems like a bug.

ms

In this case, I believe the files were non-tagged originally. So I tried importing them into RMM to make use of it's tag editor, but on import, it used the filenames as track names, numbers and all. Sure, I could fix things, but I have Linux scripts that automatically upload and tag based on the filenames etc.., so I may as well just use those.

Might not be a bad thing to have an option somewhere in JEmplode to strip track numbers on request, but probably not something that's often needed.

Cheers

Hey Mike!

One feature I really REALLY like from RMM is the way that changing a "property" (eg. "genre") of a playlist automatically does a recursive "trickle down" to all of the playlists/tracks referenced within.

Could we *please* have this feature in JEmplode too? (soon?)

Thanks!

I was going to add this today actually but got sidetracked ... I didn't realize RMM did this, but I was thinking it would be handy as well. I'm actually in the process of rewriting soups since they're sort of in their awkard teenage years now, plus I want to prepare them for multigenre (or multiwhatever) support.

ms

Okay, cool.

Cheers

plus I want to prepare them for multigenre (or multiwhatever) support.

Is multi-genre expected in a future player app release?

A lot of people are asking for it on riovolution for the Karma, so I'm sort of anticipating that at some point it's going to make the cut and I'm going to have to do it, so I figured I should get a jumpstart on it and put it in jEmplode. Right now the soup impl doesn't allow a tune to have more than one path to root in any particular soup, so bad things would happen if I tried to put it in two places in a single soup playlist.

ms

recursive "trickle down"

Hint to Mike: it's not actually a trickle-down. When you hit the Properties button, it recursively collects all of the records referenced by the item you had selected. For playlists, it just flattens the playlist. For soups, it runs the relevant query.

This allows it to populate the properties dialog properly. Then it applies your changes to that recordset.

My tunes are tagged on my PC with the track numbers included in the tracknames for whatever reason. Eg. "01 - first track". How do I tell JEmplode to strip the tracknumbers off when creating the tags for the player, so that my tunes simply show up as "first track" rather than "01 - first track" in the playlists??

You install Cantus and fix your tags. Cantus is - without a shred of doubt - the best tagger I have ever seen. It'll fix your crap tags in 10 secs flat (ok, not quite but almost).

Edit: NO! You will not use your crappy lunix scripts to upload your music! Conform damnit! ;-P

Thanks Roger -- That should save me an annoying false start

ms

Yonzie, if you have any other Linux tools for Mark, send them his way, he's pretty new at this Linux stuff and can use all the help he can get.

Yonzie, if you have any other Linux tools for Mark, send them his way, he's pretty new at this Linux stuff and can use all the help he can get.

You know... I kinda sensed that already... I'm sure he's still using fvwm2 because he doesn't know how to change it

Seriously, the biggest problem I have using linux is that with the multitude of software out there, it's sometimes hard to find the best tool for the job...

Actually, I think my vncserver still runs FVWM(1)..

Cheers

I've been having some weird behavior from saturday night's build of jEmplode. It seems that if I create a soup and then add it to another playlist by right clicking and choosiang "add to playlist", a new playlist is created called "Create a new playlist". That playlist seems to contain everything else.

However, I was able to successfully create nested playlists (soups, even) and sync them to my karma.

Deletes seem to take a long time, even though the command window output seems to indicate completion much sooner than jEmplode does. Come to think of it, all playlist transfers seem to take a long time.

Tag updates seem to cause timeouts. Maybe only when doing non-Karma tags, I haven't done a thorough series of tests to figure out when things go wrong.

Hrm. My list deletions seem to have worked, but then the additions all failed and I eventually got a "could not connect" error. My Karma still thinks that it is transferring.

After resetting, well, I didn't expect it to complete, and it didn't.
I have a log of the tail end of the errors from the transfer, if anyone is interested.

Rio Karma
Win2k
ethernet connection
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

sjs (a.k.a. SWMBO) has been using a combination of JEmplode and my own bulk upload scripts to finally dump all of her classical music collection onto George (her player), and is now very snug and content in her study listening to good tunes!

One thing she noticed tonight was that when "appending" to the currently playing tunes with JEmplode, the current playback gets interrupted briefly each time she appends a new track to the current run order. This does NOT happen when she does it via the Hijack web interface rather than JEmplode.

I wonder if that's just a "feature" of the protocol JEmplode uses, versus the serial port commands that Hijack uses .. ??

EDIT: that's with v2final and JEmplode50.

Cheers

Soups are getting a big ole rewrite ... Hopefully that will fix some of these issues.

The Add to Playlist is a weird bug related to jEmplode dynamically showing you new soups that are created (in this case, a temporary soup is created to show that list of playlists in the Add to Playlist dialog and it's not cleaning up since it gets attached to the tree in jEmplode)

Deletes are slow because of a weird problem that has existed in RMML for a while related to adding and deleting the same FID in a single connection, so I defensively drop the connection for a delete to avoid this problem. This can be disabled if you like to live dangerously.

Tag updates causing timeouts is weird ... It shouldn't ... I'll have to play around with that.

ms

Is this appending with a multiple selection or just a single selection?

Mark Emplode does the same thing, so perhaps it's the protocol. One thing I've noticed is that if the buffer is full, or rather if there is enough music queued up where it should be full, an append is less likely to happen. But if I only have one song playing in a playlist, any additions or insertions cause the pause. Does this make any sense? I think it was worse with 1.03, so the empeg guys might know the cause of it. I remember it being a bug fix.

EDIT: Other times I've been hit with this pause when there is a lot of music in the queue, so maybe it's a matter or timing or coincidence? I don't have the knowhow to really know what's going on. My "buffer" theory doesn't explain why the web interface wouldn't have this behavior.

a couple thoughts. same subject

first of all, i neveer complained about this, but when looking for a player, REFRESHING never works. i have to exit out of jEmplode and reopen, and i actually hear some disk activity on my empeg when your dogsplash is showing. if the empeg isnt ready at that time, then it will never show up, no matter how many times i hit refresh. same deal if i am already in the interface, and try to open database.

second, my empeg uses dhcp. rarely, but it happens, when jemplode restarts the player, it grabs some other IP address. this is probably because i'm using the poor dhcp implementation on my linksys router. but the result is that it doesn't recover gracefully. can't you let it try to connect to the remembered ip, but at the same time send the discovery packet to see if the ip changes?

i tested the tag sync. its so AWESOME! not sure what potential problems if there are three copies of the track on my hard drive, all tagged differently. will it be the last imported track's tags that will prevail?

Re: refresh -- I'll take a look at that ... it's a tricky problem because there are all a bunch of competing threads there and it's sometimes hard to kill them off (they're mostly all going to be blocking waiting for discovery)

Re: dhcp -- this is sort of a tricky problem ... Your lease should never expire like that. My preference would be getting your dhcpd working properly rather than writing special cases for something that shouldn't happen in a properly configured environment. But I'm open to changing my mind if anyone else is seeing this problem.

Re: tag sync -- my guess is last one wins ...
ms

It was a single selection only - didn't try multiple. But if Emplode also does it (Brad), then it's probably just a protocol thing on the Empeg side of the connection.

Cheers

There's definitely a bug with multiple selection and some of the play controls, but single selection is pretty straightforward, so I assume it's protocol also ...

Am I wrong to have hope that it could then be fixed?

Works fine already in the Hijack web interface..

I could change that impl to do a GET against the webserver if you have hijack installed ...

When doing "download" tunes from player to my computer, I've set it to name the files like this (from options):

{tracknr} - {title}{ext}

The problem with this, is that single-digit track numbers are not zero padded, so I have to go and rename the files afterwards, changing:

1 - Some Fun.mp3

into:

01 - Some Fun.mp3

Any chance of having JEmplode do the zero padding for us?

Cheers

http://jempeg.cs.caltech.edu/tagNames.html

if you do:

{tracknr:2} - {title}{ext}

it will do what you want ...

Yes, there is a padding feature already in Jemplode, I think the syntax is merely {tracknr:2} if I recall correctly.

Damn, now where'd that pebble go? It was right here a second ago...

Peachy!

Even better, "pos:2" which is what I wanted in the first place -- odd that the same spellings used BY JEMPLODE on the display don't actually work here.. "pos" instead of "Position", etc.

Cheers!

I think that Mike coded it so that if there's a no position, it'll use the track number. Or was that... If there's no track number, it'll use the position? I don't remember which...

There is actually a "tracknrorpos" tag (well, it's a virtual tag like "decade" is) I think that does this ... But there was a bug until a couple days ago that will be FITNR. I'll double check.

Each NodeTag object has a DisplayName and a TagName ... People wouldn't really want to see "pos" in the table header probably. Here are all the tags:

http://www.inzyme.com/rio/empeg/docs/api/constant-values.html#org.jempeg.nodestore.DatabaseTags.ARTIST_TAG

That's cool. The cribsheet you linked to earlier has all that I need on it, thanks!

Cheers

just noticed that the latest build of jemplode was created 1/10/04. should everyone using v50 that was downloaded when you announced it on the 8th "upgrade" to this bleeding edge one?

It's a really small fix for someone who was using jEmplode with their Karma (though it would apply to everyone). Track numbers weren't being written to MP3's properly when on download. I think that's the only real difference ...

You install Cantus and fix your tags.

My tagged albums are all nice. It's those weird bootlegs I have where the tags are a mess, and I doubt this will help.

In fact I'd be shocked if anything short of listening and recognizing the music with some sort of acoustic algorithm would help in any case (and certainly not in all cases)

recognizing the music with some sort of acoustic algorithm

you try MusicBrainz?