bad jEmplode bug

I added some new music to my player at home using regular emplode. I created a new playlist called "new!!" and copied the album playlists of the new albums I uploaded there.

I got to work and realized that I'd forgotten to load a couple of them, so I downloaded them from home and uploaded them to the player at work. I also copied those albums to new as well as leaving them in the Artist/Album structure I usually use.

I believe I synched at this point.

I then realized I'd forgotten to order the top playlist properly (my alphabetization instead of the empeg's) and I did it to one artist playlist using the up buttons. I then remembered what a pain that was, so I took someone's suggestion to put the rectified artist name in the artist field of the artist playlist so that I could sort by that. I realized that I needed to put something odd in my "new!!" playlist, so I threw a bunch of "z"s in there. I reordered, synced, and everything seemed fine.

As I left work, my currently playing album, one of the ones in the "new!!" playlist had the artist field set to all "z"s. So I figured there might have been some running list corruption, so I went to select it again. I went to "new!!" and it was empty.

Back in to work, and "new!!" is colored red in jEmplode upon initial opening of the database. I don't know why. There is definitely nothing there. The album in question has had all of it's tracks' artist fields set to all "z"s. So have all of the tracks and playlists that were in it. The only odd thing about "new!!" is that it's set to randomize its contents.

This is a huge pain. Let me know if I can help to track it down. I don't really feel like trying to reproduce it right now.

Now it's completely freaked out, keeps rebuilding the database, and ends up showing me like 0.01% of the music on the player. Reverting to plain-flavored emplode works fine, other than the zzz stuff previously mentioned.

Upon further investigation, it seems that it has propagated the artist names I set on the top-level artist playlists to everything within, ruining many a VA compilation.

Not to mention that it propagated that info from (what I consider to be) non-primary playlists. I know that there's no such thing as a primary playlist, but that just reinforces the fact that this shouldn't happen.

This isn't an option somewhere, is it?

I can't tell you exactly what you're experiencing, but I do know that there is a "feature" in jemplode whose stated purpose is to do something like what you're describing. I can't even tell you exactly what it's supposed to do, except that it seems to automatically propagate changes to a playlist's artist field to all of the items underneath. It doesn't seem useful to me, and even if it's useful to others, I, too, found out about it the hard way.

I wish to echo the sentiment that whatever this feature is be optional if it isn't already, and certainly defaulted to off.

Yeah .. No idea at all on the constant rebuilding. If you run it from the console and send me the output, it provide a little more info. As far as the propogation thing, yeah that is in there and it's from RMML (which doesn't have nested playlists except in the soup, whiere that behavior is probably more desirable).

Can we take it out or make it an option?

I've since synced with emplode (which, as I think I stated) had no problems at all, and I think that cleared up the jEmplode rebuild thing.

I think maybe it should only happen in soups.

Not the case. I don't even use the soups. It happens on regular playlists.

I mean the fix should be that it only happens on soups ... it happens on every playlist at the moment.

Oh, okay.

This is why it would be nice to have the ability to import a database from XML. Save a backup. Screw it up? You lost what you changed since you dumped the XML.

Actually, it occurs to me that it shouldn't happen on soups, either. If a song's already in a soup, then it's because it already matched the soup's criteria, meaning that the field is already filled out properly. But if the field is not relevant to the soup, then you don't want to propagate it then, either.

For example, if you have an artist soup and you find the U2 one, you don't want to change all of the tracks to say "The Joshua Tree". And there's no point is propagating "U2", since they are already that way.

The only thing I can think of where this might be helpful is on tracks or playlists that don't already have the modifed field filled out. It could also help to rectify existing playlists with mangled tags, but then jEmplode should ask in some way.

For example, if you have an artist soup and you find the U2 one, you don't want to change all of the tracks to say "The Joshua Tree".

What about genre? What about REM/Rem/R.E.M.?

Rio Music Manager has the same behaviour here as Jemplode, both for playlists and soups. Of course, Rio Music Manager can't set any properties of a playlist, so perhaps it's less confusing -- everything in that box applies to each file in the playlist, not to the playlist itself.

Peter

As you say, playlists in RMM don't have such properties.

What about genre? What soup have you gotten where you want to arbitrarily set genre across the board? I can believe that you might, but I'd think that it'd be better to ask. For example, I don't know that I'd say that "War", "The Joshua Tree" and "Pop" are all the same genre.

What about REM/Rem/R.E.M.? How are you getting to a soup that contains that set of artist tags that doesn't contain other ones you wouldn't want to also change?

I've got no problems with the idea of doing the propagation, but it shouldn't do it without asking.

I can believe that you might, but I'd think that it'd be better to ask.

I quite like that idea actually, as it's clear from this thread that people might not have realised that the properties dialog referred to a multiple selection. It'd need a "don't show me this again" box though.

What about REM/Rem/R.E.M.? How are you getting to a soup that contains that set of artist tags that doesn't contain other ones you wouldn't want to also change?

Rio Music Manager (though perhaps not Jemplode) is smart enough to ignore case and punctuation when forming soups. But a user might well want to regularise the spelling anyway, for a player which isn't so smart.

I've got no problems with the idea of doing the propagation, but it shouldn't do it without asking.

At least in Rio Music Manager, that dialog has no other function. It's always the combined properties of whatever multiple selection of tracks the user has made.

Peter

I think I wrote this for the Karma ... I can't remember if I included the commandline option to support the Empeg also. Might want to checkout the tools on rmml.dev.java.net -- it might be one of them.

The REM/Rem/R.E.M. case seems pretty clear to me -- I can't imagine you have WRONG items in there, just not normalized naming across them. I do agree it should warn before going ahead with it, though.

In reply to:

---

Rio Music Manager (though perhaps not Jemplode) is smart enough

---

Sadly, jEmplode is not smart enough ... I think I may ignore case, but I don't think I ignore punctuation. Good idea though.

ms