Tools... Upgrade Empeg ...
Select the HiJack kernel image
next >
pull down "HiJack" in the drop down box
next >
select your comport
next >
should do it

Incidentally, I only update via Serial port still ... However, I'll be adding in the FTP updating that HiJack supports.

Mike

I was afraid someone would ask for this The only reason I don't have this right now is a weird side-effect of the way the system is designed (indirectly a result of it being a port straight from emptool, which was non-graphical). The status dialog just receives update events from way down in the protocol and knows nothing of the higher level operations that are going on ... As a result, there currently is no mechanism for the dialog to reference the "Download operation" to tell it to cancel ... It's purely laziness at this point that keeps me from fixing it ... I might move this up on the priority list, though, because it's been bugging me for a while ...

Mike

Also, should cancel allow the current download to finish, or just kill it immediately? What if you accidentaly selected to download a 50 meg mp3?

So I looked at it, and the downside of this way is that if you have a non-numeric value, it will magically be turned into "0" in the playlist view (the value is still there, it's just displayed as a 0 in the table)... Perhaps this is acceptable -- It seems kind of weird that someone would put a string value in the track number anyway....

Also, should cancel allow the current download to finish, or just kill it immediately? What if you accidentaly selected to download a 50 meg mp3?

I've seen it done elsewhere such that when you click cancel, a dialog pops up asking whether you want to cancel now or wait for the current download to finish.

Incidentally, I did a quick unscientific speed test downloading a file from the kHTTPd and downloading via JEmplode and it seems to be slower in JEmplode... Is this due to some kind of overhead in the Emplode protocol?

So I looked at it, and the downside of this way is that if you have a non-numeric value, it will magically be turned into "0" in the playlist view (the value is still there, it's just displayed as a 0 in the table)... Perhaps this is acceptable -- It seems kind of weird that someone would put a string value in the track number anyway....

I'm fine with this. All my track numbers are numeric so it won't bother me. Anyone who puts text in track number fields deserves a smack anyway.

Incidentally, I only update via Serial port still ... However, I'll be adding in the FTP updating that HiJack supports.

Oh, OK, no problem then. I was thinking that JEmplode had an option to do the faster FTP method. If it doesn't have FTP then it's no different than my kernel flash utility and I don't need to use it.

Thanks anyway.

Yep... HTTP is a straight stream of the data, jEmplode has to use the Empeg protocol. Maybe sometime I'll provide an option to say "I use HiJack, download over HTTP instead" (low priority, though, right now).

I agree ... www.jempeg.org -- the new prerelease has this fix

Maybe sometime I'll provide an option to say "I use HiJack, download over HTTP instead" (low priority, though, right now).

Sounds good.. I realize it's a whole new protocol to deal with, but this would shave a lot of time off of really large downloads like the 25+ GB I am going to be doing very soon. Plus, just about everyone is running Hijack these days!

Thanks again for being so responsive to these requests.

I would suggest FTP rather than HTTP, since FTP can be used bidirectionally -- you mentioned maybe setting up FTP for kernel downloads anyway.

Cheers

Is this that issue we were told would happen? When Microsoft pulled the Java VM out of XP at the last minute, essentially disabling Java on the XP platform? Everyone was pissed about that one as I recall.

If I remember correctly, Microsoft by law had to take it out due to the lawsuit with Sun when MS tried to create their own Java version.

Dosen't matter to me anyhow, since when I install Mozilla, it grabs the newest Java Runtime from Sun when it's needed.

Hey Mike,

Sorry about turning this thread into the JEmplode tech support thread, but I tried to do a large download today and had some interestin behavior. It got through about 300 tunes and then all the files started showing up as 0 bytes. They were still taking a while to download, so I'm guessing it was actually doing the transfer, but the files were all saved as 0 bytes. Here's part of the status.txt which might provide some insight:

java.io.InterruptedIOException: Read timed out

	at java.net.SocketInputStream.socketRead(Native Method)

	at java.net.SocketInputStream.read(SocketInputStream.java:90)

	at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)

	at java.io.BufferedInputStream.read1(BufferedInputStream.java:225)

	at java.io.BufferedInputStream.read(BufferedInputStream.java:280)

	at org.jempeg.empeg.protocol.EmpegInputStream.read(EmpegInputStream.java:77)

	at org.jempeg.empeg.protocol.EmpegInputStream.read(EmpegInputStream.java:71)

	at org.jempeg.empeg.protocol.EmpegCharArray.read(EmpegCharArray.java:90)

	at org.jempeg.empeg.protocol.EmpegCharArray.read(EmpegCharArray.java:86)

	at org.jempeg.empeg.protocol.packet.TransferResponsePacket.read0(TransferResponsePacket.java:70)

	at org.jempeg.empeg.protocol.packet.AbstractEmpegResponsePacket.read(AbstractEmpegResponsePacket.java:49)

	at org.jempeg.empeg.protocol.Request.receive(Request.java:251)

	at org.jempeg.empeg.protocol.Request.waitForReply(Request.java:148)

	at org.jempeg.empeg.protocol.Request.readFID(Request.java:362)

	at org.jempeg.empeg.protocol.ProtocolClient.readFID(ProtocolClient.java:231)

	at org.jempeg.empeg.emplode.EmplodeSyncManager.downloadFile(EmplodeSyncManager.java:438)

	at org.jempeg.empeg.emplode.EmplodeSyncManager.downloadFiles(EmplodeSyncManager.java:356)

	at org.jempeg.empeg.emplode.action.DownloadAction$DownloadInBackground.run(DownloadAction.java:137)

	at java.lang.Thread.run(Thread.java:484)

org.jempeg.empeg.protocol.EmpegProtocolException: Stream did not contain PSOH. (Got -62 instead)

	at org.jempeg.empeg.protocol.packet.EmpegPacketHeader.read(EmpegPacketHeader.java:91)

	at org.jempeg.empeg.protocol.Request.receive(Request.java:191)

	at org.jempeg.empeg.protocol.Request.waitForReply(Request.java:148)

	at org.jempeg.empeg.protocol.Request.readFID(Request.java:362)

	at org.jempeg.empeg.protocol.ProtocolClient.readFID(ProtocolClient.java:231)

	at org.jempeg.empeg.emplode.EmplodeSyncManager.downloadFile(EmplodeSyncManager.java:438)

	at org.jempeg.empeg.emplode.EmplodeSyncManager.downloadFiles(EmplodeSyncManager.java:356)

	at org.jempeg.empeg.emplode.action.DownloadAction$DownloadInBackground.run(DownloadAction.java:137)

	at java.lang.Thread.run(Thread.java:484)

I wasn't using my Empeg at the time so I don't think I was doing anything that would have caused this. Has anyone else done any large downloads with JEmplode?

Someone said they had similar results when they ran out of harddrive space (all files ended up as 0 bytes)... Can you reproduce it and send me the entire status.txt file?

No running out of space here, I still have 16GB left...

I'm sending the status.txt (quite large) to your email acct. You asked for it.