JEmplode requests/bug...

Hi,

Since there's a new version to play with, I've found a couple things that I wouldn't mind having modified:

The first is more an annoyance than anything else, but in all the file selection dialog windows, the contents are sorted in the "wrong" order, where "wrong" is defined as "not in the same order they are in my shell". At the moment, directories are listed first, then files. That part is fine. However, the thing that's constantly throwing me off is that files/directories that are named with an upper-case character are sorted in with files named with lower-case letters. Traditionally upper case letters (at least in all the *nix shells I've used) are before all lower-case letters in the sort order. I'd like an option to sort things in that fashion, please.

The second bit is about downloading songs. Can it remove any id3v1 tags, and write the id3v2 tag info from the database, pretty please?

And third, there's a bug in how songs are downloaded: most of my tags specify tracknr in the style "05/14". When I download tracks, I want to have the track number as part of the name so that they list in the proper order in the directory. However, when I added the tracknr to the filename format template, and downloaded a song, I ended up with a directory named "Bob Dylan-Blonde On Blonde-05", and a file in there named "14-I Want You.mp3". The same thing happens if I have a "/" character in the the artist, source, or title fields. The best solution (I think) is to translate any "/" characters into "-" characters, although in the tracknr field, I'd prefer it to ignore the first non-numeric character, and anything trailing it (so I'd just get "05"). Pretty please with a cherry on top?

Cheers,

1) On the file dialog side, I don't have a whole lot of control here asside from rewriting the entire file dialog ... I'm just using the core Java component which is obviously not using the native dialogs. They did a lot of work on the dialog for JDK 1.4. If you're on a system that has a 1.4 VM, it may be worth upgrading to that to see if it is better.

2) I wanted to get this is for 37(-40) but just didn't have time. The tag writing part of the ID3 library we're using has some bugs still that I need to work out. But this one's pretty high on the list, so it will make it in in the next couple of releases.

3) Someone else asked about ignoring everything past the first non-numeric character. That seems like a pretty reasonable approach to it. The thing that sucks about ID3 tags (maybe some see it as a good thing, I don't know) is that there's no type information enforced -- so fields that you and I think should be numeric just allow random data.... Makes for a pain to interpret it. But I will either put a "-" in (which I need to do to other fields anyway -- like you said about title and artist) and/or make track number better.

Mike

1) On the file dialog side, I don't have a whole lot of control here asside from rewriting the entire file dialog

Don't go to the trouble on my account, then. I just thought it might be a "quick fix". The KDE file dialog boxes do the same thing, which I never understood, because it's confusing to have one behaviour in the shell and another one in the GUI.

2) I wanted to get this is for 37(-40) but just didn't have time.

I thought that might already have been an RFE, but just in case...

3) [...] That seems like a pretty reasonable approach to it.

Sweet! I look forward to being able to blow away the MP3's on disk and regenerating them from the empeg...

Thanks bunches,

With regards to number 2, can it please strip all ID3 tags (including multiple V2 tags if present) and then write out a nicely synched set of both a V1 and a V2 tag, the same way MP3 Tag Studio does it?

'Cause right now, that's what I end up doing if I want to write Emplode's data to a downloaded file: I grab the files off the player using Jemplode's file-naming tricks, then make MP3 Tag Studio write a synched V1/V2 tag to the file based on the file names.

The only problem is that Tag Studio doesn't have a field for "Genre" when writing-tags-from-file-names, so then I have to go in and hand-set the genre.

Yep -- your wish is my command...

The issue with sorting, re: upper/lower case characters, is likely to be a locale issue. IIRC, only the ``C'' locale, which is pretty much just ASCII, sorts all upper case before the lower case characters. If your locale is ``en_US'', for example, you'll see that your sorts will start mixing upper and lower cases together. Your i18n implementation may vary, though. Regardless, Java has made a point of i18n compliance, and I don't think they have anything equivalent to the plain ``C'' locale.

Edit: For example, start up a Korn-type shell (ksh, zsh, bash) and run:

LC_ALL=en_US ls

in a directory that has files that start with both upper and lower case characters, and you'll see it sort differently. BTW, it bothers me, too. Too many years of expecting it the old way, which is really incorrect.

Yep -- your wish is my command...

Is it lonely living in the bottle, waiting for someone to rub it and let you out?

I wish for riot support

I actually don't know anything about the Riot ... Does that use the same protocol as the Empeg or is it a different group inside of SonicBlue? Have they published a protocol spec for it?

It's a different group inside SonicBlue, it does not use the empeg protocols.

That's too bad ... Those teams should all unify their protocols ... That would be a big savings for SonicBlue I would think. Maybe they will going forward...

Gee, ya think?

Gee, ya think?

But that would mean the team empeg would be very busy for a long time, but seemingly producing nothing...

Hmmm

Kind of like the government!


-Zeke

Don't get me started.

At long last, I think I may have actually found a job, but it's a long term contract with the NC State Gov't, and they're being extraordinarily poky in passing a budget, which means my job keeps getting pushed back. Aargh!

Import sorting.

I'm working from memory here, so if I'm totally off track on this, just call me on it.

It would be nice if I could get jEmplode to sort on user-defined criteria when you insert new tunes. Right now, unless I'm mistaken, it automatically sorts new tunes based on their filename. If I want them to be sorted by track number, I currently have to get them sorted that way in the list and then click on the ``remember this order''-type button. Since I want them sorted that way 99% of the time, it would be nice if I could make that the default.

I know, you're saying, ``well, why aren't your tracks' filenames in correct alphabetical order?'' and my answer would be that they are, but I have an apparently insane friend who doesn't see the light on that one like you and I do. Regardless, I can see where this might be handy for other applications as well.

The issue with sorting, re: upper/lower case characters, is likely to be a locale issue.

Hmm... I never thought of that. That'd explain why the linux machines at work have that annoying tendancy, as well. I'll have to check into that, though I doubt I'd be able to convince them to switch -- they only just now took '.' off the front of the path, and that was only because it was clobbering the database of our asset management filesystem anytime someone did an 'ls'.

It'd be really nice if you could set a tag, say "sort" on each playlist to tell jEmplode to keep it sorted by that field or fields. So I could keep my Artists playlist sorted by artist[*], and each artist sorted by year+releasedate.

[*] I use the artist field on such playlists to store a surname-first version of the name, for sorting purposes.

I was planning on implementing this in emplode using scripting, so you'd just define a pre-sync or post-import hook function that did this.

Has anyone had a problem with advanced searches? FIrst of all if I just type marked and search nothing comes up. I know tracks are marked because i sorted the All Tracks view by marked files. Also I typed in a string and tried to save the advanced search however I didn't come up under the searches folder in the main view. Any ideas?

try "marked = true"

So is Emplode used for other Rio products? i.e. Eventually will there be a really cool new version released? Or is it pretty much "dead" with Empeg?

Mike

So far, only the Rio Central.

Ah, so it's not compatible with emplode, then?

I still can't get advanced searches to work on my Linux box, although I no longer get an exception when I try. (For example, ``marked = true'' doesn't work. Nor does ``marked=true'' or ``marked''.) Maybe I'm doing something wrong. Can you give me a correct example? (Standard searches seem to work fine.)

Emplode supports that, huh? It's back to the drawing board a bit on the parser, then...

Mike

DOH! I suck .. I led you on a wild goose chase ... I forgot that internally "marked" turns into values "Yes" or "No" and I don't have a filter on that field to convert it to a Java boolean (i.e. "true" or "false").

so do

marked = Yes

Note the capital Y. I'll get this worked out... Roger has rubbed it in that Emplode can do "marked", so in the name of American pride, I too must support that.

Mike

Bingo, the capital Y wored. Thanks!

The rules for emplode are that an empty string evaluates to false. Anything else evaluates to true. We set marked to "yes" or to "".

I am also having a bug when trying to autoupdate hijack with Jemplode. I open the database and then get this error:

at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at java.net.URL.<init>(Unknown Source)
at org.jempegjempeg.util.HijackVersionTracker.findLatestRelease(HijackVersionTracker.java:308)
at org.jempeg.empeg.util.HijackVersionTracker.isNewerVersionAvailable(HijackVersionTracker.java:308)
at org.jempeg.empeg.util.VersionTrackerUtils.upgrade(VersionTrackerUtils.java:46)
at org.jempeg.empeg.util.VersionTrackerUtils.upgrade(VersionTrackerUtils.java:26)
at org.jempeg.empeg.util.VersionTrackerUtils.upgrade(VersionTrackerUtils.java:18)
at org.jempeg.empeg.emplode.EmplodeConnection Manager$InitFromConnectionRunnable.run(EmplodeConnectionManager.java:133)
at java.lang.Thread.run(Unknown Source)

Damn that took forever to type. Any ideas? TIA

you typed all that? You can't copy and paste it? What a pain ... Sadly, though, you're missing the very top part which actually tells what the exception was

I would check your options and make sure the URL to Hijack is configured properly. You can remove .jempegrc in your home directory to have all the options regenerated.

The correct values are:
Hijack URL: http://empeg-hijack.sourceforge.net
Hijack Mk Version: mk2

Well I found out the problem. My stupid ass must have deleted the URL to hijack. Dude, are you f$%^ this up? You are being very undude... Anyways, thanks for the help.

Still though, jEmplode responded in a pretty retarded way ... If you have a blank URL, and it has a default value, ti should just go back to the default. At least it should handle it better than it did.

ms

I'm not sure if this is a bug what, but its weird. When I mirror the Artists/Album soup, the positions all change. This isn't cool because when I want to listen to an album in a particular order it isn't in the correct order.

Edit: Just checked it out some more, it seems that the mirror sets the order according the track name. It alphabetizes then sets the order.

Just pretend 41 never existed and mirroring isn't supported. I'm rewriting it. Such is the life of the prerelease.

Hehe, don't worry, it still works pretty well. You are doing an excellent job. I'm just happy you finally got the soop mirroring.