I've been using jemplode for years now, without any issue. But, It's been a long time since I've tried to download files from the empeg to my PC HDD. Now, I can't seem to be successful in doing so any longer. If I select a playlist in Jemplode, right-click, download, select a directory in my PC HDD, then download apparently starts and progresses, even though it is clearly too fast. Then, when it has done, I get this error message for every file it tried to download: "Unable to get an input stream onto the requested FID". On my HDD, I find the exact directory tree I expect, as well as MP3 files: but, they are all 0 bytes.
Can anyone help?

Thank you!

... and, I am using Jemplode 70, HiJack 476, 3.0Alpha11 .

try unchecking "use hijack when possible" in the jemplode settings and report back results.

Hi Claudio,

There are two other software identifiers that may be even more important to know here:

1. What operating system/version on the PC, and
2. What Sun Java version on the PC.

Just now, I used Jemplode v70 to download playlists from a v3a11 player here and it worked fine. On Linux (Kubuntu Hardy) with Sun JRE v1.6.0_0 as the java runtime. No problems.

I run jemplode with this commandline (from a script, actually), from within the same directory that holds the jemplode.jar file:

java_jar jemplode.jar

The exact files I use are here for you, as there may be some doubt as to the exact version of jemplode (duplicate version numbers seem to abound..).

Cheers

Thank you Mark and Tony. I'll try asap and let you know.

Mark, i got the same errors on Win Vista Ultimate x64 and Win Server 2003.
I downloaded and used the lates JAVA vm from java.com.

I used on both the same jemplode v. 70 (which in fact reports v. 69 from the help/about menu).

I downloaded the files from your server and will be trying them soon.

YESS!
In the rush of getting this done, I did use Mark's files (jemplode boot logo looked like the one I was using) and unchecked the "use HiJack when possible", and now it is happily downloading my entire collection to my server HDD. So, one of the two remedies (or both) did work.

Thank you so much!

For the records, the reason why I am in a hurry is that next weekend I'll be traveling and I just bought my first iPod from the Apple store (yes, I gave up and got one). I'd like to load it up before I leave, and since I have 80GB of MP3s to download, it will take it at least two days... Oh well, I guess I'll wait.

Now, I am realizing Jemplode most likely will download the same MP3 file more than once if it happens to be in more than one Empeg playlist. Is it the case?

Also, I did write ID3 v2 tags in all my encoded MP3s as acurately as possible. However, assuming I left out some file, would it make sense to tell Jemplode to retag them all while downloading? Definitely the empeg database and tagging ssystem is the most updated and accurate I have...

Okay, that should be the same version (6.10) as for Linux, so no big difference there.

I might try it again here from within a WinXP VM..

Seems to work. I used a command window and typed java -jar c:\jemplode.jar to run the same barebones single-file version, and it downloads just fine.

Yes, Mark, in fact, as I was saying above, it now works with me as well

Thank you!

Okay, good! For the record, my tests all had "use hijack" *checked*, as it should make zero difference in the end result, other than things happening about twice as fast as with it unchecked.

Cheers

Ok, too bad I applied both your and Tony's suggestion at the same time. I can't tell if what is making the difference now is a later version of jEmplode or the "Use HiJack" option. What is it supposed to do, anyway? I am guessing some network-related thing? If so, maybe it is a network setting we should be looking at...

The "use Hijack" option just tells Jemplode to use FTP to move files between the PC and player, rather than the proprietary empeg protocol.

cheers

Ok, so it seems problems are not over, unfortunately.

After downloading my entire collection off the empeg, I finally created my HDD-based media collection.

And to my surprise, many tunes are full of glitches, and sound quite bad both on my PC and on the iPod (which just skips the worst fo them). Their copies on the Empeg sound perfectly, and when streamed via the empeg web interface they are also sounding fine. So, it really seems that the jEmplode download process damaged several files.

Has this happened to anybody here? Maybe if I could het the "use HiJack" option to work I could re-download all tunes (4 days... ) successfully?

I have not yet tried to download them using emplode. Maybe that will work.

Thanks in advance for any help you will provide!

The "use hijack" option has the benefit of using TCP, which means packets will have checksums and be retransmitted if in error.

Dunno about the native protocol.

cheers

Right...
Mark, is there anything that should be done in the hijack menu so that "use hijack" option works?

Nope. Just get rid of any FTP user/passwd you might have set up in the config.ini file (or teach them to JEmplode).

Other than that, it just works.

The native protocol also uses TCP.

Peter

Does the web interface also let you download a file? If so, it might be useful to do a web download of a damaged file, and compare the two, so we can see what sort of corruption has happened.

Peter

Empeg web interface in theory allows downloads, but it does not seem to work on any browser here.
However, I downloaded the fid via ftp.

on www.ilquen.it/download you can find a mp3 which gets skipped regularly by the ipod, and it's empeg version which works well on the empeg: i downloaded via ftp and hopefully did not damage it.

... I also put two more mp3s, one with and another without glitches. The difference is clearly audible. And, the one without glitches was downloaded again via ftp from the empeg.

Something definitely happened while I wa susing jemplode...

Both your "pairs" of MP3s are different rips -- they have different ID3 tags and everything. It's not like one is a failed attempt to download the other. (Unless Jemplode is being really clever and re-tagging the tracks. But I didn't think it did that.)

I also can't help noticing that both the OK ones claim (in ID3) to be ripped with Audiograbber and encoded using Lame, whereas both the "glitchy" ones claim to be ripped with, uh, "Taym's Grab & Encode"

Peter

In other words, I think you've got two copies of each of these songs on your Empeg. As each pair shares the same title, album, and artist, Jemplode probably downloads both to the same place, overwriting one with the other, and leaving you with an arbitrary one of the two. Meanwhile, following your usual playback menus in the web interface gets you only to the good versions.

It's even possible, I suppose, that it's the very existence of these duplicates that's confusing Jemplode's fetch-using-Hijack code.

Peter

Ok. So yeah the tags are different somehow. Looking at the Thomas Newman track basically 4 bytes are replaced with zeroes every 16kB. So the tracks were the same and from the same encoder before getting corrupted at least

Possbily whatever created the new tag with "Taym's Grab & Encode" has also munged the file?

Yes, it does have that feature (retagging on download from empeg). Maybe that's where it's mangling the file.

Mmm.. I just tried a few combinations of download settings in JEmplode, and none of them messed up the file. But there are a lot of possible combinations left to try.

Can you post your JEmplode settings for us?

On my Linux box, these are saved in a file called "jempegrc". if you could search for that file on your computer and post it here, that would be best.

Cheers

Actually they are not different rips. They are the same rip. jEplode retags the MP3 upon download, and that's one of the main reasons why I had to use jemplode. I already have almost all fids on my hdd, but I was not sure they had the right tagging inside, so that even using some renaming sw would not be an ideal choice.
In addition to that, I used iTunes to change some of the tagging. The mp3s are, however, the same rip.
"Taym's Grab & Encode" is the comment I use in my empeg to classify the mp3s I grabbed and encode. I use to add that comment once they are in the empeg, so it is not in the FID/mp3's id tag but in empeg db. Once I download the file from the empeg to the hdd, jEmplode updates the ID3 tag including my comment.

Sure. Here it is. In Windows, it is located in "%userprofile%\.openrio\"

Guys, thank you so much for helping me look into this.

Now, if there are 4 bytes replaced with zeroes every 16kB, that seems like a pattern. I doubt it is caused by random connection issues....

Thanks.. hang on while I try it, or parts of it.

The first suspect may be the "remove ID3v1 tags" option..

EDIT: nope, not by itself anyway..

Seems to be fine here. Strange.

This is with the jemplode.jar that I provided to you earlier, and Sun Java 1.6.0_0-b11 on Linux.

EDIT: actually, it's with a jemplode.jar that is 1969173 bytes in size, with md5sum of 8ffea0cca6c5669dc5153061dbaa2e21 .

So, since the files get corrupted when you do it on Windows, the obvious advice becomes: re-do the downloads on Linux.

What's the filesize (and md5sum, if possible) of the jemplode.jar that produced the errors?