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?

It's the one I got from your server, Mark:

1,846,532 bytes.

md5sum is: b12df779f039afbcdf2eaa524ffbe5b6

Edit:
which looks different from what you have there.

Edit:
Your jemplode.jar is larger in size. Can we assume you are using a newer version?

Ahh.. maybe that's it.

I've just dropped the one I tried it with here, onto my server for you. I called it jemplode.jar.v69.0000000000000000001.

Grab that and try again?

Meanwhile, I'll try with the other one here.

Oh, by the way.. I just repaired one of your tuners here a few minutes ago.. listening to radio with it now.

Cheers

Thank you for both! Tuner repaired is already a great news Now I am trying the other jemplode. Hopefully that's a good news too...

Downloaded. I'll let u know.

Second tuner also now works. I had to replace the RF modules in both of them -- one got a factory original pinched from an NFG tuner I got from Hugo's junk pile (thanks Hugo!), the other got one of the PCATS modules, with appropriate modifications as described in an older thread.

The two old failing modules were removed using hot air, and could perhaps be repaired someday. Rumour has it that an op-amp chip inside the module is the problem. So I'll file those in case I someday need them, and then try to identify/find/replace the op-amps.

Cheers

Mark,

Please feel free to keep BOTH RF modules for yourself, in case they can be fixed and used by somebody in the future.

And, just mail me one of the two radio modules. I think I'd prefer the one with the original Tuner.

----

Back to the mp3 transfer issue:

The newer version of jEmplode seems to work fine. I transferred both files again and they sound fine. iPod does not skip them either, to confirm that the reason why it would so so is exactly that the files were corrupted.

Now, i noticed that this issue with transferring mp3s was quite random in the first place, so I really hope this is solved by using the newer jEmplode. But, there's no way to be 100% sure. I am going to re-trasnfer everything. I'll do so in batches, so I can check if everything is ok. It's going to take forever...

Again, thanks for all the help.

Shonky, what did you use to compare the two files?

... and, for the records, in this version of jEnmplode I can use HiJack as a downloading option. Which I am doing, just to be on the safe side. If anything in the download protocol was not fixed right since the previous version, I may be having the same problems again, so I am going with HiJack. I will be crossing my fingers. For the next 3 or 4 days.

Edit:
I am sorry, it still does not work. At the ened I still get all 0 bytes files.

Bummer.. Got a Linux system you can do it on instead? Nary a problem with it here.

Cheers

Or.. here's another idea, which might be feasible.

You could just ignore Jemplode, and use a recursive FTP client (eg. wget or ncftp on Linux (there might be something similar on Windows) to just grab the entire /empeg/fids/ heirarchy from the player.

Then run a script afterwards to rename the files from hex to something meaningful (artist, album, title, etc..) from the associated tag files. (I think there's already a script that does that, somewhere, but again.. trivial on Linux).

And finally another (or the same) script to copy the empeg tag information back into the ID3v1/v2 embedded tags. This should also be a simple script on Linux, doing callouts to mp3tool to modify the files.

If you were doing it on Linux, I could even save you some effort, and quickly cobble up a bash/awk script to do all of that.

Cheers

Wget is available for Windows, too (and I think it also comes with cygwin).

No, Mark, no Linux box here handy. And, so far this version of jEmplode still seems to be working ok.

Hexworkshop. Best hex editor I've found so far (there's a lot of crap ones) - not 100% happy with it but it does the job for most things I need.
http://www.hexworkshop.com/

When you've done the compare you can click on the lines in the screenshot I sent and it will highlight the data in the files.

Ok, I finally completed another full download of all my MP3s from my Empeg via Jemplode. Successfully. No glitches at all.
It really seems it was an issue with an older version of Jemplode.
Thanks Mark for giving me the better jemplode version, and thanks Shonky for pointing me to HexWorkshop. And thanks everyone for the help.