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