there's a prerelease jEmplode that supports uploading a HiJack kernel on www.jempeg.org ... I'm talking to Mark about how to add in an autoupdater (i.e. check for latest kernel, then upload automagically).

Mike

This new version does have the +1 position incremented, as you said, however, when I download files using the {pos:2} field, I now get the following unusual output for the position field:

The B-52's - Cosmic Thing (1989, Rock) - 01 - Cosmic Thing.mp3
The B-52's - Cosmic Thing (1989, Rock) - 11 - Dry County.mp3
The B-52's - Cosmic Thing (1989, Rock) - 21 - Deadbeat Club.mp3
The B-52's - Cosmic Thing (1989, Rock) - 31 - Love Shack.mp3

... despite the fact that the "Position" column in the main window clearly shows those tracks as being ordinary 1, 2, 3, 4 in position.

Is there a "position = position + 1" statement somewhere in the code that's being misinterpreted as a string concatenation instead of a numeric addition?

Why yes, yes I was Grab it again...

I'm having trouble getting jemplode to run. I downloaded the installer w/ vm and installed on my WinXP system, and it runs fine, though when I replace the .jar with the prerelease version it gives me errors when trying to start the app.

java.net.ConnectException: Operation timed out: connect

 at java.net.PlainSocketImpl.socketConnect(Native Method)

 at java.net.PlainSocketImpl.doConnect(Unknown Source)

 at java.net.PlainSocketImpl.connectToAddress(Unknown Source)

 at java.net.PlainSocketImpl.connect(Unknown Source)

 at java.net.Socket.<init>(Unknown Source)

 at java.net.Socket.<init>(Unknown Source)

 at com.oroinc.net.DefaultSocketFactory.createSocket(DefaultSocketFactory.java:56)

 at com.oroinc.net.SocketClient.connect(SocketClient.java:167)

 at com.oroinc.net.SocketClient.connect(SocketClient.java:253)

 at org.jempeg.empeg.emplode.Main.main(Main.java:46)

 at java.lang.reflect.Method.invoke(Native Method)

 at com.zerog.lax.LAX.launch(Unknown Source)

 at com.zerog.lax.LAX.main(Unknown Source)

 

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.

Supposedly, Microsoft would provide a link which allowed you to download the necessary files to get Java running. Perhaps try the Microsoft web site.

Or am I remembering it wrong, was it some other feature they yanked?

If it is the XP/Java thing, I would hope that the InstallAnywhere packager should properly detect and warn the user in that situation. Does JEmplode need to be built with a more recent version of the InstallAnywhere packager?

Oops .. I think you're seeing an sideeffect of some new development that I was working on ... I'll put a new prerelease jar up later tonight that fixes this ... if you wanted to fix it, you can unzip that jemplode20.jar and delete the com/oroinc directory then zip it back again (and rename it back to a jar).

Mike

Ignore my previous comment -- the latest prerelease beta just had a goofy version of the startup class. I'm putting a replacement up now.

Thanks. Works great now.

Did you figure this out yet?
Or are you waiting for a reply from me.. ?

Cheers

Hi Mike. I'm trying JEmplode out for the first time. Excellent work! It's very full featured. However, the one thing I want to do with it right now is download my MP3's so I can do a massive re-tag and re-organization. I did a test download of one track and it worked, but now when I select Download, nothing happens. It worked once, but now the dialog doesn't even pop up. I checked the status.txt file and I get this exception:

Exception occurred during event dispatching:

java.lang.NullPointerException

	at java.io.File.<init>(File.java:180)

	at org.jempeg.empeg.emplode.action.DownloadAction.performAction(DownloadAction.java:92)

	at org.jempeg.empeg.emplode.action.DownloadAction.actionPerformed(DownloadAction.java:118)

	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)

	at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1504)

	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:378)

	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)

	at javax.swing.AbstractButton.doClick(AbstractButton.java:279)

	at javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(BasicMenuItemUI.java:886)

	at java.awt.Component.processMouseEvent(Component.java:3715)

	at java.awt.Component.processEvent(Component.java:3544)

	at java.awt.Container.processEvent(Container.java:1164)

	at java.awt.Component.dispatchEventImpl(Component.java:2593)

	at java.awt.Container.dispatchEventImpl(Container.java:1213)

	at java.awt.Component.dispatchEvent(Component.java:2497)

	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)

	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)

	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)

	at java.awt.Container.dispatchEventImpl(Container.java:1200)

	at java.awt.Window.dispatchEventImpl(Window.java:926)

	at java.awt.Component.dispatchEvent(Component.java:2497)

	at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)

	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)

	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)

	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)

	at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)

I tried restarting JEmplode but no luck. Any idea why I can't download anymore?

Did you choose your root directory or something to save into? I'm uploading a new jemplode20-prerelease.jar to www.jempeg.org that I think will fix your problem.

Mike

Did you choose your root directory or something to save into?

You got it. I have a network shared drive dedicated for the task of holding my MP3's and I was using the root directory. Thanks for such a quick (almost mlord-esque) turnaround!

Hey Mike... Any chance you could allow directories to be created with the download feature? Like maybe I could specify a template like:

{genre}/{artist} - {title}.mp3

Or somethihng like that? Right now it seems to be turning / and \ characters into underscores.

The underscore thing is a safety net since on Windows you can't have files with /*\? (and some others) in the name.

As far as your request, right now, downloads are more designed for downloading from the playlists, not from the soup (where it will just put files into directories like your playlists are organized) ... But I can imagine that you might want to download from the soup into dirs too.... Let me think about a general fix for this. It may be that you define a soup download format and a non-soup download format to handle cases like what you want to do....

Mike

Well, does the download feature remove duplicates? Like if I right click on my root playlist and download, is it going to download 2 or 3 copies? The reason I wanted to download from soup was so I could get exactly one copy of each track.

I like the idea of a soup-specific download format. I'll be happy to test it out for ya.

Let me think about a general fix for this. It may be that you define a soup download format and a non-soup download format to handle cases like what you want to do....

My dream:

To be able to download the entire contents of the player onto a PC's hard disk, in one shot. It automatically creates a soup tree of artists/albums/songs. It also creates a handful of playlist folders, each of which contains M3U files pointing to the songs.

Then, have the connection software (whether it's Jemplode or Emplode or both), when the time comes to re-format my player and re-load all the songs, optionally interpret this tree structure as soup-entries-and-playlists just like I downloaded it.

Backup and restore.

The empeg guys keep hinting at how Emplode will eventually be a full music manager. I'm anxious to see whether or not a backup/restore/dupe-check system becomes part of it.

Grab the new prerelease from http://www.jempeg.org . This adds a couple features you might find interesting:

1) a new option for setting a separate soup download filename format
2) a new option for setting the download directory (so it doesn't bring up a file chooser every time if you have a standard download location)
3) a new option for making all files download with their "full path" -- before, if you selected a single tune and downloaded it, it would just save a file "yourtune.mp3". With download with full path on, it will always save as "Playlists\PlaylistThatContainsTune\tune.mp3".
4) duplicate downloads are skipped (right now duplicate = does the file exist -- I'm not checking file size... I can if you think it should)
5) you can include paths in filename formats (both soup and non-soup), so you can say "{genre}\{title}.mp3". However, if full path is on and you download from the "Artist\James Taylor" playlist, it will automatically put it in that path for you.

Mike

I've been considering this for a couple days actually (specifically the idea of a big soup directory of tunes and a set of .m3u's rather than recursive directories). Do you know if an m3u can reference another m3u? (i.e. nested playlists like the Empeg supports). If so, this dream could definitely become a reality.

Mike

Also, do you think people would want both styles? (i.e. one that actually puts the MP3's into the playlist directories and other that creates a big soup of FID#.mp3 and a bunch of m3u's)

Do you know if an m3u can reference another m3u?

Not in the original M3U specification, no. Perhaps you can add your own extension to the text stored in the M3U file so that it works with your software. It won't play in WinAmp, but hey...

Another option would be to simply create folders for all the playlists, and have the M3Us in each folder only point to songs. That might be a little cumbersome I would agree.

Does anyone know of any PC-based software that supports nested M3Us? In other words, is there already a standard for doing it?

Hmm I'm trying to understand what you mean by "duplicate = does the file exist." That makes sense if you're just downloading into a flat directory structure, but with Empeg's nesting, I don't see how this works.

Real life example: Let's say you have two genre playlists at the root level, say Dance and Pop. Say a song appears in both.. If JEmplode were putting them in the same directory, I can see how it would detect that the second is a duplicate by checking if the destination file exists.. But what if you're just grabbing the entire root playlist? It seems to me it would create a Dance playlist and put the song in there, and then create the Pop playlist and that song would be created again... Based on what you're saying about "does the file exist."

Here's how I would do it: When the user downloads, have an option to eliminate duplicates. Then as each file is downloaded, keep track of the FID being downloaded. Later on, if the same FID comes up from a different playlist, check its existence in the list of files already downloaded and skip it. This might chew up a little bit of memory, but it shouldn't be that bad.

Or is that how you're already doing it and I'm just not understanding?

Off to try the latest and greatest release.

Another thing, is a confirmation dialog really necessary for downloads? I can understand for deletes, etc...

And one more request, can the numeric fields (particularly track number) sort in numeric order instead of text? When I sort by track number it goes 1, 10, 11, 12, 2, 3, 4 instead of 1, 2, 3. I realize this could cause some issues if you've got non-numeric stuff in those fields for some strange reaosn, but I'm sure you can figure that stuff out

Edit: Now you guys know how I got to Veteran status.

This thread went off topic fast (my fault). It was originally about how Jempeg could update a Hijack kernel to the empeg.

I wanted to do this for the first time today, using the latest Jemplode build (neat options for downloading soup songs and adding paths, by the way, thanks), but I couldn't see where in Jemplode I was supposed to upload the kernel. I had to resort to using logoedit to do it.

Where is the option to send a kernel to the player through hijack?

I'm not currently doing this ... Your second paragraph is correct. This modification is just a quick hack so that if you download a playlist, then download it again later, it won't download the same files twice. I think just leaving out files that have already been downloaded is not exactly what we want to do (I think it will be confusing to people, and will not work across download sessions), rather I think a little bit clearer solution would be implemented like the subthread of this discussion that Tony and I and talking in now.

The problem with this is that you can have refcount > 0 playlists too... so I think you have to have nested playlists in m3u's to make this work.

Edit: Now you guys know how I got to Veteran status.

So what's with the Edit:, aren't you aiming for the next level?

/Michael

The only reason I did this was because downloading is a lengthy operation, and I wanted to make sure the user was certain that he/she wanted to perform that operation.... I can disable this (maybe this is a configuration option?). I debated on this one because I agree that it's a little weird -- you usually don't confirm a non-destructive operation .... I'll think about this one a bit.

You're right that it doesn't do this currently because there is no enforcement in the ID3 tags that this value is supposed to be numeric .... I'll take a look at what would happen if I make it a numeric sort w/ a non-numeric value.

Yeah I hear ya.. How about a "cancel" dialog on the downloading progress window? Like if a user hits cancel, it'll finish the current track and then stop. Then there's no long-term commitment to a download...

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.