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

Fixed:
1) M3U's with relative paths work
2) jempeg.soup.count was renamed to jempeg.soup.num (YOUR JEMPLODE-ONLY SOUPS WILL DISAPPEAR, SIMPLY SET jempeg.soup.num=<number of soups you had> TO BRING THEM BACK (or recreate them))
3) if tag not set in V2, use tag from V1
4) interactive search computes before attaching to UI (much faster)
5) numeric columns are right justified
6) search soup doesn't allow playlists
7) transient soups were increasing refcounts

Couple things in this release -- A search soup can contain playlists, but it will never contain a soup playlist (to avoid infinite loops). Soups will also not show tree colorization (also to avoid infinite loops right now, though the first fix probably prevents that problem now).

The deal with reference counts now -- transient playlists (jemplode-only) will not increase the reference count of a node (unless you copy and paste part of the tree onto the empeg, in which case it becomes a persistent playlist and the count begins... I haven't dealt with what happens if you copy and paste a transient playlist and then delete it in the same session -- you're on your own there -- just use persistent soups for that -- I may even disable this later). Additionally, there is a new value on a node that keeps track of the number of NON-SOUP reference counts (persistent OR transient), and this is the value that is now returned when you talk about "refs" in the search engine. So the reference counter is left intact, but there is another "non-essential" value that is used for display and queries. Keep in mind that a node that appears to have a zero refcount in jEmplode may actually have a real refcount > 0 if it is in an on-Empeg soup, but most people don't care about that.

Oh well.. give this one a shot..

Mike

I've been playing with this latest pre-prerelease today, and I have to say that it's looking pretty good.

Now I need to go out and buy some more CDs so I can see how well it uploads stuff....

Great! I'm going to fix the color selection problem now that I have that handy luminance calculation (I'll have to find what the breaking point is) and a couple other misc things that I have in my list (and I'll give this release a little bit of time to get other reports in) then I'll put it out ...

Mike

The only issue I have seen is the toolbar buttons are huge now.

Hey, when I paste a soup into a regular playlist, is it doing the 'soup' thing?

Thanks,
rjf&

pretty snappy! just started playing with this, and am having some success. just a couple of questions:

what is the search syntax? (i.e. wildcards, NOTs, etc.)
can a soup playlist criteria be edited after it's created?
are the soups dynamically updated as new music is added?

this is great work! thanks for putting in this effor!
-ted

I tried thenew beta today.
It seems to work pretty well but i dont seem to be able to delete files in the soup views.

Also is there any examples of tricks you can do with soup creation ?
like being able to create complex structures dynamically ?
ie
all albums / a / artist 1 / album 1
all albums / a / artist 2 / album 1
all albums / b / artist 1 / album 1
all albums / c / artist 1 / album 1

If you run with 1.4, the toolbar buttons shouldn't be huge (you can tell if you're using 1.4 if the buttons are flush to the toolbar, if they have huge ugly Windows 95 looking borders around them, then you're still using 1.3).

So the deal with pasting is:

If you copy and paste the top level of the soup (i.e. the node you actually named when you created the soup), things may get a little weird -- I haven't really tried this one. What it _should_ do is just make a copy but it won't update... I'm not sure when it resyncs if it will try to attach twice to the same playlist.

if you copy a subplaylist of a soup, that should work properly (say just one artist of the By Artist soup). It will automatically update with the artists -- Unless you delete the soup playlist that it came from, then it will become just a static playlist (basically you have to have that top level node -- that is the trigger that attaches the soup to receive updates).

The copy-and-paste of soups is something I haven't spent a lot of time testing so far, so if you do try some of these scenarios, let me know how it goes ... I will do some of them too...

Mike

http://www.jempeg.org/tagNames.html -- at the bottom is the search syntax (same as Emplode basically)

Soups will update dynamically as you add music.

Currently you can't edit the criteria ... Well .. I take it back, you can't edit the criteria through the UI. There are two different types of soups. The jEmplode-only soups appear in .jempegrc and can be edited there (there's a message in the original Prerelease announcement thread that talks about the format). For on-empeg soups, the top level soup node has a new tag in it called "soup" whose value is the same as the soup values in .jempegrc. You can edit that value with the Advanced Tag Editor tab of the Properties dialog for the playlist. The soup won't actually update until the next time you sync though.

I have soup deleting turned off right now (by turned off I mean "not written" ). It will be in the next release though. Keep in mind that deleting from a soup = deleting from the entire Empeg. if you were to just delete the ref from the soup it would just recreate it the next time you sync.

I haven't really thought about that kind of soup... Let me give it some thought... Currently you can layer tags and searches, so you can do "By Artist / By Decade / By Album" or "All Marked Tunes / By Artist", but it looks like you're talking about a new soup type that is like a modified of By Tag that would be By Tag <split on first letter> or something like that .... Probably won't make this release, but I'll think on it some...

Mike

thanks for the info mike. as i was playing with it some more, some other stuff came up:

i am trying to create the equivalent of a wendy filter. so i am removing bands i dont want to hear (i.e. not artist = "band that sucks" and not genre = "sucky genre", etc). i did this on a soup tagged by artist, and it synced fine. however, when it booted up the next time, jemplode found playlists with 0 refs, and added them to the root.

i added a refs>0 statement in the search, but still have the problem.

also, are the searches order dependent? i tried doing the following sequence to generate a soup: filter on artist first, then adding the tag, then adding another search for refs>0. even with that, i am still getting blank playlists when i reboot the rio.

as long as i dont resync after jemplode adds the blank playlists, then the playlists on the rio look correct (i.e. no blanks).

hopefully, this makes sense.
thanks
-ted

I'm not sureif I downloaded PrePre2 or 1 but...

I decided to start fresh after the last fiasco so I deleted everything from the empeg and synched. However, I had to go back several times and repeat the process of deleting to actually kill them all...some were there after the the empeg restarted each time.

After I deleted all, and no playlists or tumes were showing up in jemplode, I noticed that I still had 27 songe on the empeg...but no playlists. I cannot figure out how to delete the superfluous tunes now.


Schrag Doll, livin' in a movie
Hot tramp, daddy's little cutie...

(sorry Mike...I couldn't resist)

Bad Things happen if I try to expand a soup (using the handle to the left of its icon) before it has been fully populated:

java.lang.ArrayIndexOutOfBoundsException: 122 > 119
at java.util.Vector.insertElementAt(Vector.java:551)
at javax.swing.tree.DefaultMutableTreeNode.insert(DefaultMutableTreeNode.java:178)
at javax.swing.tree.VariableHeightLayoutCache.createNodeAt(VariableHeightLayoutCache.java:714)
at javax.swing.tree.VariableHeightLayoutCache.treeNodesInserted(VariableHeightLayoutCache.java:433)
at javax.swing.plaf.basic.BasicTreeUI$TreeModelHandler.treeNodesInserted(BasicTreeUI.java:2355)
at javax.swing.tree.DefaultTreeModel.fireTreeNodesInserted(DefaultTreeModel.java:466)
at javax.swing.tree.DefaultTreeModel.nodesWereInserted(DefaultTreeModel.java:289)
at org.jempeg.empeg.model.FIDPlaylistTreeNode.playlistNodeInserted(FIDPlaylistTreeNode.java:216)
at org.jempeg.empeg.nodestore.FIDPlaylist.firePlaylistNodeInserted(FIDPlaylist.java:107)
at org.jempeg.empeg.nodestore.FIDPlaylist.insertNodeAt(FIDPlaylist.java:477)
at org.jempeg.empeg.nodestore.FIDPlaylist.createChildPlaylistAt(FIDPlaylist.java:676)
at org.jempeg.empeg.model.AbstractPlaylistNodeModifier.createChildContainer(AbstractPlaylistNodeModifier.java:216)
at org.jempeg.empeg.soup.TagSoupUpdater.nodeIdentified(TagSoupUpdater.java:170)
at org.jempeg.empeg.soup.TagSoupUpdater.nodeIdentified(TagSoupUpdater.java:151)
at org.jempeg.empeg.soup.TagSoupUpdater.initialize(TagSoupUpdater.java:135)
at org.jempeg.empeg.soup.SoupUtils$SoupInitializeRunnable.run(SoupUtils.java:272)
at java.lang.Thread.run(Thread.java:484)

When this happens, the UI hangs for a bit. Eventually it returns but redraw is screwy (in a way that's hard to describe), movement (up and down) doesn't always take you where you expect, and items are missing from the soup (I think it's things with higher-numbered FIDs that are missing). HTH.

And my "Orphaned Items" search still finds things that don't really have refs-0 - perhaps we need to wait until the empeg-car playlist is built before any soups that use refs? As a workaround, it'd be nice to have a "Recompute soup" item on the popup menu for a soup view.

So you actually have an account on the infamous Empeg BBS Good to know that you can annoy me both in Instant Messenger AND on the BBS

So the way this is supposed to work is that you will have tunes that do not have references (not in a playlist) but still exist on the Empeg. Until the next release you can't _delete_ from a soup playlist. The soup you want to setup to find those missing tunes is probably Add Soup Playlist=>Search, and do Advanced Search and makes the query "refs = 0" and see if that shows the tunes. Unfortunately you can look but you can't touch. However, you can probably copy and paste them into a non-soup playlist and delete the completely from there.

Mike

The next PrePre is going to be a little while -- My father in law (who has had leukemia) has taken a turn for the worse and I need to spend some time with my wife and her mom. I'll probably return towards the end of next week -- if nothing else than to destract myself.

Keep reporting issues though ... I'll check in.

Mike

thanks man! I'll give it a shot when I get home and let you know.

I would have continued to keep my "annoyances" contained within the world of AIM but you weren't on. "Why are you yelling and screaming at me?" hehe

There probably is a bit of order dependence .. I need to try out some scenarios, but I suspect if you put the search first, it will prefilter the nodes and they won't trickle down to the by Artist. On the flip side, if you do By Artist first, you may end up with empty artist name playlists since it might create the artist playlist then decide not to put anything in it .... It probably _shouldn't_ be order dependent, but I'm too stupid right now to work through that one ... I'll try it out.

ms

mike,

i think your presumption is correct. (and the expected behavior). i think order dependence (if planned for, and used properly) is good because it gives you more options.

what i am curious about is all of the empty playlists jemplode added when i rebooted the empeg. see if you can duplicate that when you get a chance.

best wishes to your family.
-ted

Hey Mike,

I just wanted to say this is really cool. I just had one of my hard drives die and take all my playlists with it (it was the smaller drive and I think contained the root FID, but few if any actual mp3s). I have managed to rebuild 99% of my original playlist structure just using the new soups! I don't think I need regular playlists anymore. Too cool.

But, one question. It looks like the soup definitions are stored in the .jempegrc right? So what happens if I sync with jemplode on another machine, or with emptool? Will the soups get ignored, destroyed, or updated? Maybe the soup definitions should get copied onto the player either in config.ini or a special soup fid to ensure that they are there from any machine (running jemplode) that a user chooses to sync from?

Thanks,
-Mike

only local soups are stored in the .jempegrc

the ones stored on the empeg are in the tags!

-t

There are two types of soups actually -- one is in jEmplode only (that is in jempegrc) and the other is on the Empeg (there is a new tag "soup" on the top level playlist that defines the soup). In Emplode, that looks like just a regular playlist and is ignored. Maybe I can store jEmplode-only soup defs in config.ini like you were sayinng though.

Mike

Sweet. Gotta love it when software works better than you expect it to

-Mike

Well, now that I have played with it for a few minutes, I have a feature request. Soup dedupping. When I add a file to a soup it should dedup the same was as when I add a file to a normal playlist (figure out where the file goes and if it is already there don't upload again).

Thanks,
-Mike

Yeah .. all the operations on a soup besides them basically working need to be worked on ... I stuck importFiles(..) into the soup at the last minute. I'll take a look at it for the next release.

So it turns out this is kind of a hard problem, actually .. when you import into a soup, it doesn't actually just add directly to the soup, rather it just adds to the database and the soup is updated in the background. That means that to do this we really need the more general deduping at the database level (which is a somewhat substantial amount of work).

So it turns out this is kind of a hard problem, actually

Database level deduping would be pretty cool though. No duplicates anywhere, ever. It is a shame you can't get a checksum back from the player. Actually, couldn't you just md5 (or whatever) every file before upload and write the result into the tag file?

-Mike

Yep ... The annoying problem is what to do with tunes already on the Empeg. It would take FOREVER to recompute hashes for tunes that don't have them.... Maybe give people the option to if they want, otherwise it's just "dedupe from now on".

Yep ... The annoying problem is what to do with tunes already on the Empeg. It would take FOREVER to recompute hashes for tunes that don't have them.... Maybe give people the option to if they want, otherwise it's just "dedupe from now on".

I would think that dedup from now on would be good enough. I for one would be willing to reload all my music to get database wide deduping.

-Mike