jempeg.sourceforge.net

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

Serendipity is just the name i gave to a project that I've wanted to work on for a long time ... Basically, I find that my mp3 collection stagnates on the Empeg. I wanted to find some way to get new material introduced to my unit. So what Serendipity does is combine a source of recommendation data with a music downloading service (in my case, I prototyped with AllMusic for data and LimeWire for tunes). Basically it goes to picks random tunes from your empeg and goes to limewire and finds related artists and then goes to limewire and tries to find songs by those artists, downloads them, and syncs them to your Empeg.

More pseudo-technical info:
http://empeg.comms.net/php/showthreaded.php?Cat=&Board=hackers_prog&Number=128527&page=0&view=collapsed&sb=5&o=0

ms

maybe try !hash or !(hash)?

nope and nope. i looked up advanced search in the faq and it listed not as an alias to !. so turns out

not(hash)

worked for my purpose. thanks.

So if I want the latest standalong version (44) I go to http://jempeg..org/ (which is redirected to http://jempeg.cs.caltech.edu/ ).

It if want the newest version I download the whole thing over again?

-----

Is this connection to limewire useful for people on modems (like I have at home)?

Can I turn this off? I usually use JEMPLODE at work (becuase you have to be an admin to install empeg on NT) and they will not look favorably to starting a limewire server.

not sure if its implemented, but if it isn't, consider this a feature request

is there any way possible to make jemplode follow shortcuts/symbolic links and add references if a crc match is found? much easier to organize on the hdd than jemplode.

Right now www.jempeg.org and jempeg.sourceforge.net are out of sync ... the latest installer is at jempeg.sourceforge.net, but I haven't decided where it ultimately will reside. So yes, if you want the last standalone, it is at jempeg.org (because I haven't moved the old links over). However, what would have been Build 45 does not currently have a standalone version and can only be downloaded with the full installers from jempeg.sourceforge.net. This is because the Limewire stuff requires a bunch of jars to work. I will pick back up in build 46 with the smaller releases though (as replacements for the jar in the full installer). Technically I could release the version the same way, but it would just fail when you try to use the LimeWire stuff (which may be OK, since not everybody needs/cares/wants it).

I use LimeWire over my modem ... One thing I do is start it before I go to bed and let it download stuff over night. It won't affect you at work, because it only (currently) runs on-demand -- so if you don't select it from the menu, it won't run.

Mike

If you can get me specs on how shortcuts are implemented on Windows, I might be able to ... Symbolic links (I think) will work for free, since it would just appear as a regular file. And CRC matching _should_ just add a reference currently (currently = 44+)

here is the .lnk format in a pdf file. hope this is what you're looking for.

i've been thinking about a couple of features that would be compliment the crc checking pretty well. i tried to interpret the jemplode source and see if i could try and implement it myself, but my java is just too amateurish.

i usually drag my whole mp3 folder to sync up my empeg w/ the hdd. of course, this takes time w/ the crc check on 30+gigs... so i end up leaving it for a few minutes. if you can have a toggle in the configuration to auto-sync after adding/dragging folders, then it would be great.

the next thing that i thought up was to shorten the amount of time to crc check. i was thinking a local database with 4 fields {filename, datemodified, song-crc, tags-crc}. the tags-crc would consist of both id3v1 and v2. the logic goes like this:

(no change) if the filename / date are the same, crc checks do not happen.
(additional file or filename change) new filename, crc checks happens. it then checks if theres a song-crc and tag-crc that matches already. if so, it updates the filename. if not, then gets appeneded to the database.
(tag change only) crc checks happen. if the song-crc is equal but tag-crc is not, tags get modified on the empeg to match the local song.

the tag-change this is a special case, since most tagging software do not change the datemodified, and therefore wouldnt be caught. a seperate button to do a full rescan of crc-checks would solve that. i'm sure i'm missing some more logic, but you get the idea. this would give an awesome speed boost to the checking, dont you think? or would this be too hard to implement?

Just curious as to the status of USB connectivity for the Mac under OS X. Any progress? Would this be faster than over ethernet?

Haven't worked on it in a while ... I wouldn't hold your breath for this one being done any time soon. Mike

Report from Classic Mac OS using Apple's lame-o Java (MRJ 2.5.5).

Finally found time to install v45 (full install) on my OS 9.2.2 box at home.
Reinstalled the swing1.1.1 stuff from my 8.6 partition and it sort of works.

It connects via Ethernet and finds the unit. It downloads the databases. The playlist listing opens, but none of the actual entries in the playlist show up in the right hand pane (only time anything shows up is when you click on the empegcar entry and one entry - playlists).

Also the little arrow things don't work if the branch has not previously opened by double clicking.

Search doesn't work. Create Soup Playlist doesn't work unless you just select all (which shows up in the left hand pane, but you can't see if anything is in it since the left hand pane doesn't work).

A lot of the other stuff is working. Grab EMPEG screen, Configure player, etc.

No big deal as I usually rip on the Mac and FTP to my free/ancient PC then upload from there.
----
USB is 12Mb/s and 10BT Ethernet is 10Mb/s - so there is not much of a theoretical advantage for USB and in actual use I think the reports are close.

Yeah -- I think I figured out what's going on ... One of the methods I'm using isn't documented as being added in JDK 1.2 even though it was. It's basically the method that fires an event when you change playlists. Oops.

That would be a pretty good speed boost in most cases ... I'll save this one and see how it works out.

ms