Is Mike still out there doing any work on JEmpeg? I had always hoped for a sync feature....

-Ted

Last I heard, he was trying to get empeg functionality into the RMM Lite thing that was developed for the karma. That was a week ago.

I've been praying for him to add genre and year into the tags of files downloaded through Jemplode... Seems like an easy fix...?

- Jon

Yeah -- I'm still here ... I've been really busy with work for the Karma and we just got a new puppy, so I haven't been able to focus much. Two things hold up a release right now 1) because of the Karma, I ported Rio's MP3 parser -- however, I only ported reading, not writing. That means that writing tags back out is currently broken. It's a popular feature, so I don't want to release without it. I may keep the previous id3 lib in just for that feature until I decide what I want to do (I hate having two libs that do almost the same thing), and 2) my development Empeg has died and I haven't had time to open it up to look at the IDE cable + headers.

ms

I've been praying for him to add genre and year into the tags of files downloaded through Jemplode... Seems like an easy fix...?

The nice thing about open source is you can fix things yourself rather than spend all your time praying for them Even if the original author is busy with something else. Find jemplode.jar on your hard drive and replace it with this version which should fix the genre/year bug (you may need to use GetRight or something like that to keep your browser from mangling the file).

-Mike

p.s. The actual bug is in the (closed source) id3library jemplode uses, but there is a simple enough workaround. The updated EmplodeSyncManager.java is here.

Oh hey -- That's cool Can you email me a patch file with your fixes when you get a chance?

Hey Mike,

Thanks for uploading those 2 files...

I'm no Java programmer, in fact, as you'll see in a second... I'm no Java file download/installer either...

So where should they go and what should I do?

I installed both in the C:\Program Files\JEmplode 2.0 directory. When I run Jemplode, it comes up as v45, which is good b/c I used to run v44. A dialog pops up when I select my empeg. The dialog asks if I want to upgrade to v44. Of course, I click "upgrade later". I then get an error that says "This application has unexpectedly quit" with these details...

java.lang.NoClassDefFoundError: com/tffenterprises/music/tag/id3v2/Frame
at org.jempeg.empeg.emplode.EmplodeContext.setPlayerDatabase(EmplodeContext.java:164)
at org.jempeg.empeg.emplode.EmplodeContext.setConnection(EmplodeContext.java:197)
at org.jempeg.empeg.emplode.dialog.ConnectionSelectionDialog.showConnectionSelectionDialog(ConnectionSelectionDialog.java:141)
at org.jempeg.empeg.emplode.Main.main(Main.java:85)
at java.lang.reflect.Method.invoke(Native Method)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)

What am I doing wrong?

- Thanx in advance!
- Jon

So where should they go and what should I do?

First off, get all of 45 installed. Go to www.jempeg.org and run the installer according to the normal instructions. Then you will have to figure out where it puts jemplode.jar and replace it with the first file I linked above (you don't need the second linked file).

-Mike

Ok, deleted the old jEmplode completely then installed v45 from the installer and then replaced the installed jemplode.jar with the one you have posted above.

jEmplode now loads ok. I tried to download one album and jEmplode seems to leave more than half of the songs as zero byte files. jEmplode reports that it failed to download a bunch of songs but the reason is just "http://10.100.30.75/drive0/fids/480" and "http://10.100.30.75/drive0/fids/4E0" and other file locations...

Any idea why this is now happening? The good news is that the songs that it DID download now have the tag filled out in their entirety... Getting close!

- Thanx
- Jon

http://10.100.30.75/drive0/fids/4E0

Let me guess, you are running a very recent version of hijack right? Mark's changes for the new fid directory support break jEmplode's "use hijack where possible" feature. Go into jEmplode's options and uncheck the use hijack box.

-Mike

Oh.... that's a tricky bit.

Mike: you gonna fix this, or shall I?

Basically, accesses to fids should now be done via /empeg/fids[01]/ instead of /drive[01]/fids/ -- use the exact same pathnames that the player uses for those directories. Hijack will automatically translate to subdirs from there as required.

Cheers

Mike,

Yup. You are right.

Thank you VERY MUCH for your help in getting this working. Ahhhh - my tags feel so much better now!!! :-)

- Jon

Hijack will automatically translate to subdirs from there as required.

Is it tough to make Hijack translate both possible permutations instead of just the one? There might be a lot of people who are running older Jemplodes.

I think that people running older JEmplodes are probably also NOT using the new subdirs. In which case it probably works as-is, or does it?

Hijack prefers not to mangle the REAL pathnames under /drive[01]/fids/* because that might interfere with backups and rsyncs and people storing 3rd party apps in those places.. Much better to only mangle the symlink paths that the player uses, under /empeg/fids[01]/*

Cheers

So if I change jEmplode to use the new folder structure, how recent of a hijack do you need? That is, if people aren't 100% up to date on their hijack, will it not work for them? Should the format be an option, or should it force them to upgrade their hijack?

ms

No, do not change it to use the new folder structure.

Instead, merely change the path it uses to be the same that the player software uses: /empeg/fids[01]/* instead of /drive[01]/fids/*

This will work will all players and all Hijacks.

Cheers

Hm. Not trying to be picky, as my tags are now working, but downloading seems to take FOREVER now. Is it because I'm not using ftp with Hijack now?

- Jon

That would definitely be a symptom .. it is several times slower to download with the protocol instead of ftp.

Hijack v345 is now available.

The only change is that FTP now includes code to mangle accesses to the FIDS directories, to hopefully restore JEmplode compatibility for the time being, until JEmplode gets updated someday.

Try it and let us all know if it works or not.

-ml

Mark,

I did try it out...But It looks like, that it's still the same problem. The downloaded file has still a 0 kb size.



bye

Ah yes ... Sorry, Mark -- I lied in email earlier ... I just checked and I DO do a LIST (actually, I think it's an NLIST, whatever that does). This is how I retrieve the file size of the thing I'm about to download. Hence the 0 file size. Is there a better way to get that? It's been so long since I worked on this code, I can't remember why everything works the way it does anymore.

ms

I think if JEmplode were to do a LIST (or NLIST or whatever it's called) on JUST THE ONE FILE it wants to know about, then that will work fine. But trying to list the entire directory will require that JEmplode "know about" the possibliity of subdirs etc.. and then things get very messy.

But.. I just tried that myself now, and get an error, so I suppose this (the [N]LIST) isn't going to work.. I'll think about it for a spell..

Cheers

I suppose JEmplode will have to do it this way:

Split the 8-hex-digit FID into 5-digit subdir, and 3-digit subFID.

Try to access the files as /empeg/fids[01]/subdir/subFID
If that fails, then try /empeg/fids[01]/FID

When uploading, just use /empeg/fids[01]/FID and Hijack will convert it to a subdir (creating the subdir if need be) as required, if required.

-ml

I think the next jEmplode is almost out anyway, so it will use the new folder structure -- will that fix this problem? Is it just that list doesn't work for the faked folders?

If JEmplode is going to use the new structure, then it MUST be clever about it, preferably in the same way as Hijack. Otherwise we are going to see infinite confusion and pain as a result.

For any fid retrieval, first look for the the subdir'd fid, and if that fails, then look for the flat directory (original style) fid.

For any fid WRITE, only *only* use a subdir if at least one subdir already exists. If at least one subdir already is there, but the one you need is NOT on either drive, then create it and then upload the fid to it.

And again, use /emped/fids[01]/* as the base pathname for everything.

Cheers

Can the same subdir exist on both drives?

Yup.

OK -- Does this look correct?

RemoteImportFile.getInputStream: couldn't find http://192.168.0.101/empeg/fids0/_00001/d80
RemoteImportFile.getInputStream: found http://192.168.0.101/empeg/fids0/1d80

ms

Yeah, that looks right for a player that is NOT using the new subdirs.

Cheers

Note that, so long as you're just retrieving the files and not doing "ls", it is sufficient to merely use ONLY the second format (from your posting). Hijack will translate it to the new format internally if appropriate to do so.

Cheers