I moved part of the site back over to sourceforge.net and also bulit a new set of jEmplode installers for 2.0b13 (which is actually build 45). I haven't put up build 45 jemplode20.jar's yet because this release has Serendipity built in (the download-from-Gnutella-based-on-AllMusic-recommendations system) and requires a bunch of other jars to work properly. I think the requirement will be that you grab the full installer and I'll start up doing replacement jars in Build 46. Check under the "Apps" menu to access it.

http://jempeg.sourceforge.net -- the link to the installers is the top left one. Try it out and let me know how it works.

I haven't moved the old jars over to sourceforge yet .. I'll do that tomorrow probably.

Mike

Looks cool; I'm trying Serendipity now.

Only thing "bad" is one of the java_vm processes seems to be chewing 78% of my CPU. Not sure why, and I don't think I'm worried about it yet. If it happens consistently I'll see if I can figure out why, but this is only my first invocation

Actually... this is really going to piss off people who don't like people who aren't sharing anything trying to download, isn't it?

I haven't added the configuration option to allow you to share music yet, though you can go into limewire.props that gets created in your home dir and define a share directory that includes your local music. Limewire, at least, allows people to set that they only allow downloads from people who have uploads. Short answer -- yes. Long answer -- i'll work on it.

Mike

Is this during normal execution or just while running Serendipity?

It turned out it was a jvm started by mozilla, the java applet which offered to install jemplode went nuts. I killed mozilla and the problem went away. I reopened the page and it came back.

It looks cool just the same; I was just thinking ahead before people started ignoring my (real, not dynamic or ISP NAT) IP address because I was a leech

I downloaded the new installer and ran it. However, it doesnt seem to work. I get the following error every time I run serendipity.

See Attached

One stupid method call that's JDK 1.4 only (appending a StringBuffer to a StringBuffer vs. a String to a StringBuffer). I can't tell from your screenshot what OS you're on -- I assume that means it's Linux ... I _believe_ there's a Linux 1.4 JDK available -- Try grabbing that (java.sun.com). I'll remove that method call from the next version. Sorry about that ..

Mike

How does Serendipity do deduplication? Particularly I've seen it thrice trying to download stuff that's on the empeg it's talking to.

Yep .. This is just the first cut at the entire system, so there are a lot of issues like this to work out. So basically it's basically prototyping that AllMusic and LimeWire integration. Next up is to make stuff nicer. Deduping is a really hard problem in general though ... Nobody ever tags correctly, and most likely the hash code that's computed for you tune is going to be different than that of the one it's downloading.

For some background, there are a couple layers to Serendipity:

First is a Ranker -- This is basically the thing that can give a list of the most highly ranked tunes on your Empeg (some algorithm that decides what types of things you really like or don't like -- basically the data set that it will base recommendations off of). The current implementation of a ranker is RandomEmpegRanker -- basically it just picks random tunes off your Empeg. Clearly there are smarter implementations of this in the future.

Next is the Recommender -- This takes your Ranked tunes and uses some algorithm to provide recommendations of other tunes that should be downloaded (actually it returns metadata about tunes to download, so that could just be "all songs by Artist X" or a specific tune. Currently it recommends based only on artist by ripping data from AllMusic.com . This could be layered with other recommenders that basically take a set of recommended metadata and run it through a filter to remove things you already have to address some of the problems you're seeing.

Third is a MusicProvider -- This is basically a place it can go to search for tunes that match the criteria returned by the recommender and download them. Right now is pretty blindly goes out to LimeWire (gnutella) and searches for String format of the metadata with "mp3" attached to the end and just downloads up to a certain number of matches for each recommendation. This is another place the filter could enter in (i.e. try to figure out if you already have this tune -- probably a variation on the Ranker that the provider passes matches back through the ranker so the ranker can decide whether that tune should be downloaded or not -- right now it doesn't do that stage).

Clearly each of the stages is the first draft, but the basic system is here. One of the things I'd like to add in is a rating system like TiVo has so it can be smarter about what it tries to download -- number of plays is a pretty good way to do that now, probably.

Mike

There have been a lot of questions about this one -- I regret making the decision in the first place, but after like 43 or so, the default soup playlists were removed (with the intent being that you could choose which ones you wanted). I shouldn't have done that because it's just created confusion.

So the deal is that the features is still there (a lot fancier, actually) but there just aren't any by default. If you want your By Artist, By Album, By Genre, etc back, check out

http://jempeg.sourceforge.net/faq.html

At the bottom is a "How do I make custom soup playlists?" question with some examples. I'll bring the defaults back in 46.

Mike

Nobody ever tags correctly
Yeah. Very annoying.

On the other hand it's making very good guesses

Running windows, 1.4.1 Java. Still does the same thing :-(

Really?? Did you download the Windows installer that included the VM? I'm actually uploading a modified jar file for Tony that adds some configuration options for more debug output ... It happens to have a fix in there to use the old method. http://jempeg.sourceforge.net/jemplode-debug.jar ... You should be able to replace the jemplode.jar with this one. Let me know if that fixes your problem.

Ok, I went back and uninstalled everything - java and jemplode - and then went back and loaded up everything with install anywhere off your site. It works!!! Thanks!

Serendipity, cool. I can't seem to connect though. I just get the "Waiting for hosts... 0 connected" for 30 seconds or so until it times out. Limewire seems to work fine on this machine so I don't think it is a network issue. This is on OS X 10.2.2 with either the stock 1.3.1 jdk or 1.4.1a6. Any ideas?

-Mike

I honestly haven't tried it on my OS X box yet ... I'll try it out and see what's up.

Before I get there to try that out, you could try stealing your gnutella hosts (is it called gnutella.net, maybe?) files from limewire and putting it in jEmplode's working directory (not really sure what jEmplode's working directory ends up being on OS X). See if that list of hosts can jumpstart jEmplode?

ms

try stealing your gnutella hosts

Doesn't seem to make any difference. jEmplode creates a gnutella.net in the same directory as the jEmplode application so I assume that is the WD. I replaced it with the gnutella.net from limewire and I have the same problem.

-Mike

Hi.

also bulit a new set of jEmplode installers for 2.0b13 (which is actually build 45)

I just yesterday installed that (the versions which included a JVM). There seem to be a small inconsistency with that build45 version. It reports to be version 45 in its title bar, but when I turn on automatic jemplode updates, it tries to 'update' to version 44.

HiJack updates work as expected though.

cu,
sven

Yeah ... Since I allow non-numeric versions, I can't order the version numbers, so I just look if your version number is _different_ than the one on the website... The problem is that you can't just upgrade from 44 to 45 (easily)... The best I can do right now is change the version number on the site to 45 so it doesn't try to upgrade 45 people, but 44 people will have to go up to 45 or it will do the same thing to them (but they can't just upgrade -- so it's kind of misleading).

Oh well .. you can turn off jEmplode autoupdating for right now. I'll post on here when it's turned back on.

Mike

build 45 is great. it fixes the "uploading the file even if it exists" bug.

now i have a question. is there any way to search for a null value? i'd like to know which tracks are without a hash value, and would like to re-up them using jemplode.

hmm.. have you tried

hash = ""

? that might do it.. i think nulls turn into "" in the tag value retriever.

first thing i tried. gives me a "No more tokens on this line" error.

whoops.
that sucks
maybe try
!hash or !(hash)?

Mike,

Is the genre tag issue going to end up in a coming build? The issue is that it isn't being populated...

- Thanx
- Jon

there are several other jars that need to get installed for 45, so right now there's not just a jemplode.jar ... you can use the installers on the top left to do the initial install to get them initially. The dead 44 link is because I haven't moved the old jars over from jempeg.org to sourceforge yet. I'll probably pick back up with jemplode.jar on 46.

ms

I don't know if genre writes back out on download yet .. i don't think i worked on that one. This release was a totally selfish release I mostly only worked on Serendipity (OK, there were a couple fixes in there).

ms

Ok, do y'all have a site that I can go to where I can read up on Serendipity? I don't know much about it and want to brush up...

A Google search gave me lots of links to the lame-ass John Cusack movie...

- Thanx
- Jon