Well .. after many long nights, the new version is really close. I wanted to let the daring grab it and try it out to help catch any goofiness before putting it up. I've gone through the basic things (adding different soups, dleteing soups, deleting non-soups, downloading, synchronizing, importing).
Known issues:
1) Loop checking in the UI isn't in (though it is done at download time). So if you paste a playlist into another playlist that causes a loop, it will let you, but it will be fixed after the next download. This will be fixed for the release.
2) Pasting into and deleting from soups is not done yet (they just do nothing right now)
3) "Find Container Playlists" has gone bye bye for now ... This is primarily because soups are now actually playlists, and since you could setup a search that finds containers and itself would create containers, you can get into some nasty infinite loops -- this is kind of tied into #1 but even nastier.
4) Download w/ Full Path isn't working right now (Playlists have many parents, and I haven't decided how I want to track that path information). It will download fine, but it will only create paths for one level back up.

Notable things:
1) dmz put tag rewriting on download ... Check out Tools=>Options to turn it on
2) soups everywhere -- on the empeg, off the mpeg -- Checkout Tools=>Add a Soup Playlist... Essentailly each row of the list corresponds to a layer of the soup, so to have a "By Artist=>By Album", you would "Add Tag Layer=>Artist" then Add Tag Layer=>Source (Source = the generic name for Album). You can choose to add the soup onto the Empeg or only to jEmplode (this is like the old way)..

Notable things with soups: You should be able to copy sections of the soup and have them continue to update _as long as the soup you copied them from still exists_. If you remove the top layer of the soup, the sub-copies will stay there, but they won't update any longer. It is technically possible to have this work, but it seemed like more trouble than it was worth for now. Along these lines, there may be weird problems if you copy a subsection of a transient (jEmplode-only) soup and then delete the entire soup... I'm not positive if the copy will stay around or not (haven't gotten around to testin this).
3) Toby's new XML format is in there ... a lot easier to work with than the Emplode format.
4) There are several colors (and they go up the tree again). There is a dirty color (red), a "colored" color (blue), and a dirty-colored color (purple). Would people want a separate "marked" color? It's already checking marked, it's just not colorizing.

Anyway ... This has all the usual caveats of a hot-off-the-presses release, though I've spent a lot of time redoing a lot of the low-level system to make it more stable.

One thing I'm very curious about is the performance of the soups on Empegs with several thousand tunes. One performance note is that you may want to wait to open the soups until after their icon is set (you'll see what i mean). As soon as you open the soup, it has to calculate all the children and then it does quite a bit of event firing and array resizing to keep the tree in sync with the soup. This is an area I will be working on quite a bit, but you were warned (if it is taking a while to get the soup up to date).

I highly recommend JDK 1.4 ... I have not tested this on anything but 1.4 so far. I haven't even tried it on my Mac w/ 1.3 yet (I'll do that tomorrow), so if you have a Mac, fire it up and let me know how it goes.

The look and feel defaults to the system look-and-feel now ... On 1.4 I've tweaked a couple things to make the Toolbar look more natural... I'm curious what people think about this as opposed to Metal (the Swing look-and-feel). Anyone have any other look-and-feel preferences?

Anyway -- give it a shot... let me know what happens:

http://www.jempeg.org/jemplode20-supersecret.jar

ms

non-existent tags defaulted to -1 ... I changed that for dynamic data so it defaults to 0. Existing 65535's will still be there, but it shouldn't make any more. You can use the advanced tag editor to change old ones.

Also -- for those who "enjoyed" the previous release, you'll enjoy even more the hundreds of previously dead playlists that got left hanging and are now added to your root playlist... Cheera.

Here's what I get when I try to run it. I have 1.4 installed.
This is on W2k

Thanks

java.lang.NoClassDefFoundError: com/sun/java/swing/plaf/windows/WindowsToolBarUI

at java.lang.ClassLoader.defineClass0(Native Method)

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

at java.security.SecureClassLoader.defineClass(Unknown Source)

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

at java.net.URLClassLoader.access$100(Unknown Source)

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 org.jempeg.empeg.emplode.Main.main(Main.java:74)

at java.lang.reflect.Method.invoke(Native Method)

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

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

Here's what I get when I try to run it. I have 1.4 installed.
This is on W2k

I get similar on Linux:
java.lang.NoClassDefFoundError: com/sun/java/swing/plaf/windows/WindowsToolBarUI
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:493)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at org.jempeg.empeg.emplode.Main.main(Main.java:74)
at java.lang.reflect.Method.invoke(Native Method)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)

Ditto here... on XP w/ JDK 1.4

Ditto all those dittos On OSX 10.2

-Mike

Me too, I'm afraid.

I'll publish my playlist stylesheet (in its own thread) when I am able to run the new JEmplode.

Couple things:
1) I'm uploading a new one that won't have this problem -- give this about 10 mins

2) If you have 1.4 installed, but you run jEmplode with the executable, you are actually only using 1.3 (the VM that it comes with -- which is why this problem occurred). Instead, you should double click the jemplode20-supersecret.jar or run "java -jar jemplode20-supersecret.jar").

Oh yeah -- one other thing -- you may want to turn off autoupdate, since 42 will try to "update itself" to 41.

A brief scan with the latest pre-prerelease (20020820b) looks slightly worrying - all my soup views and searches have disappeared. I didn't change anything in ~/.jempegrc, and your release notes don't say to expect this.

Forgot to mention that -- expect this ... For now anyway.. If people are terribly annoyed by this, I can write an importer. Just make a copy of your .jempegrc in your home dir for now.

Actually -- you can convert your stuff over pretty easily ... the .jempegrc format is the following:

jempeg.soup.count=3
# a search example
jempeg.soup.0.name=Name of First Soup
jempeg.soup.0.externalForm=search:(title contains test)

# a tag example (By Artist)
jempeg.soup.1.name=Name of Second Souip
jempeg.soup.1.externalForm=tag:artist

# All marked tunes, then By Artist
jempeg.soup.2.name=Name of Third Soup
jempeg.soup.2.externalForm=search:(marked)~tag:artist

Basically the externalForms are ~ separated... You should be able to convert over relatively easily if you have a lot of them and you don't want to use the UI.

Mike

Okay, thanks. I didn't have any custom soups; I was surprised to lose the default ones, though.

I see from your examples that searches are just a special kind of soup. That makes a lot of sense, really.

I debated the default ones ... I ended up ditching them because I don't know what performance is going to be like yet on large collections and i thought people would prefer to just pick the ones they want.... Assuming there aren't some huge problems, I will be spending most of my time on performance between now and releease ... I grabbed my 15 license for OptimizeIt Pro, so I need to maximize my time

ms

I don't seem to be able to delete any soup listings I create from jEmplode. When you delete them they are removed from the playlists, until you exit the program and return or resync with your Empeg.

A cosmetic issue with the new colours: when they are highlighted, they become very difficult to read (this was an issue in v40 as well, IIRC). See attached.

is this an on-Empeg or in-jEmplode soup? And you deleted the top level playlist? and then synched after you deleted it?

A couple of searches are giving me strange results:

jempeg.soup.5.name=Orphaned items
jempeg.soup.5.externalForm=search:(refs \= "0")
jempeg.soup.6.name=Items with optional features
jempeg.soup.6.externalForm=search:(((options like "x") or (options > "0")) and (not (options \= "0x0")))

"Orphaned Items" contains about a fifth of my tunes, but they all have refs between 2 and 13, not zero. I believe it should be empty. (Hmm, what runes do I need to get my All Tunes soup back? Search on (type="tune"), perhaps?)

"Items with optional features" is empty, even though I can see a handful of playlists with non-zero options.

The following two searches work fine:

jempeg.soup.7.name=Marked tunes
jempeg.soup.7.externalForm=search:((marked like "yes") and (type \= "tune"))
jempeg.soup.8.name=Fixed-rate tunes
jempeg.soup.8.externalForm=search:((bitrate like "fs") and (type \= "tune"))

see what happens if you remove the quotes from the numeric values ...
just out of curiosity

I briefly thought about how to get All Tunes back too ... type=tune would do it ... fid > 0 would do it also. maybe a blank search (haven't tried this one).

Can someone briefly explain what "soup playlists" are please?

- Jon

In reply to:

---

see what happens if you remove the quotes from the numeric values ...

---

No change, AFAICT.

soup playlists are playlists that are created on top of the "soup" of tunes on your Empeg. Originally, all tunes on the Empeg had to be put into playlists. In the 2.0 serious, this restriction was removed, which meant you had to have different way to view your tunes to see them... Enter "the soup" -- Views like "By Artist" or "By Album" are examples of soup playlists. Basically these are dynamically generated views of your tunes based on some criteria.

I won't be able to look at this till i get home tonight, but if you get some free time, can you split that query into its components and see if they each individually return the correct results? I'll add this example to the stress tester for the query engine too ...

Uploading m3u files never worked for me in v40, so maybe I'm doing something wrong.

I have a compilation album, and wanted individual artist folders and an M3U playlist file with the running-order of the compilation. In other words, the m3u file looks like

Artist 1/Track 1.mp3
Artist 2/Track 2.mp3
...etc

JEmplode happily imports all the files normally, but then complains about each one rthat it eads from the playlist file:

org.jempeg.empeg.tags.UnknownFileFormatException: Unknown file format.
at org.jempeg.empeg.tags.TagExtractorFactory.createTagExtractor(TagExtractorFactory.java:84)
at org.jempeg.empeg.tags.TagExtractorFactory.createTagExtractor(TagExtractorFactory.java:72)
at org.jempeg.empeg.filesystem.AbstractLocalImportFile.identify(AbstractLocalImportFile.java:112)
at org.jempeg.empeg.nodestore.FIDLocalFile.identify(FIDLocalFile.java:126)
at org.jempeg.empeg.nodestore.FIDLocalFile.createInstance(FIDLocalFile.java:59)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.importFiles(AbstractPlaylistNodeModifier.java:100)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.importFiles(AbstractPlaylistNodeModifier.java:92)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.importFiles(AbstractPlaylistNodeModifier.java:92)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.importFiles(AbstractPlaylistNodeModifier.java:92)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.importFiles(AbstractPlaylistNodeModifier.java:60)
at org.jempeg.empeg.emplode.ui.NodeModifierUI$2.run(NodeModifierUI.java:48)
at java.lang.Thread.run(Thread.java:484)

I thought it was supposed to add extra references to the already-uploaded FIDs?

Later: it works if I use absolute filenames in my M3U file.

And a couple of other things I noticed, trying my first jEmplode upload (I normally use emptool, so I may be doing stuff wrong): a track that had an ID3v2 tag with no year didn't pick up the year value from its ID3v1 tag instead, the "refs" tag has large values on uploaded tracks - consistently 8, except for the files in the M3U, which are 9. Is this because references from the soup are being counted, perhaps?

I'll take a look at the m3u import ... So is the Artist 1 directory relative to the directory the m3u file is in?

What did you mean about adding extra references to the already uploaded FIDs?

I don't believe that the tag parser currently falls back to loading data out of the v1 tags if it isn't set ... I may be able to do this -- I'll have to check.

You're definitely right about the soups increasing refs ... Both jEmplode and on-Empeg soups increase refcounts... Never really considered this. This one is probably worth a bit of a discussion, but clearly jEmplode-only soups should NOT increase refcounts, so I'll fix that one.... However, on-Empeg soups is another issue. I'm not really sure how I feel about this one. It's "lying" to not increase refs on-Empeg since they really are regular references.... I need to look more into what problems may occur if I secretly don't increase references for soup playlists even on the Empeg.

ms

I obviously can't split the (refs = 0) search...

Splitting the other one may have turned up something useful - all the items I've set options on are playlists, and none of the searches have returned any playlists, only tunes. Perhaps this is where the problem lies? Version 42 returned both tunes and playlists, unless you explicitly selected one or the other using (type = "tune") or similar.

Yeah this is kind of mentioned in the release notes ... I haven't dealt with showing playlist matches right now to avoid loops. Once I decide how I want to handle loop checking then I will put playlist search results back in...

the refs = 0 failing makes sense now given the realization that the soups are refcount increasing.

I'll try out this query at home tonight and see what's up...

In reply to:

---

What did you mean about adding extra references to the already uploaded FIDs?

---

I meant that I expected it to upload the tune once, and put it into two playlists. And that's exactly what happens with a M3U containing absolute names, so there's no bug there.

In reply to:

---

is the Artist 1 directory relative to the directory the m3u file is in?

---

That's what I was doing (I was generating the M3U file using "find * -name '*.mp3' >playlist.m3u"). I ought to check what Grip generates when you tell it to produce a M3U file. Can anyone here give an authoritative statement of whether this is the correct way to write M3U files, or, better, point us at a specification?

Later: this is exactly what Grip writes. So, for example, I can do something like "xargs ls -l <./playlist.m3u" and have it work, if I'm in the directory that contains the M3U file.

As to the issue with on-player soups - I haven't used any of these yet (though I might put a "Marked tracks" view on my player sometime), so I don't know what the Right Thing is. I would go with counting them at least for now, and only consider changing that when we're confident that there are no other bugs that could interfere (so we are more confident that subsequent misbehaviour is due to this).

I have to admit that I didn't correctly understand your comment about loops in the release notes. Now I understand that my searches for playlists won't work, at least for the present.

In reply to:

---

the refs = 0 failing makes sense now given the realization that the soups are refcount increasing.

---

Does it? Remember that the problem is that lots of things were appearing there that had refs>0 (it should be an empty result set). Or is the problem that refs is changing all the time as the views are built, making it essentially random what value refs has when it's looked at?