The new JEmplode is out. This release is compatible with the new 2.0 versions of the Empeg player. There are too many changes to even list at this point. The most notable are:

• compatible with Empeg 2.0
  
• support for artist/album/etc playlists (like Emplode)
  
• rewritten ID3 tag parser (compliments of Daniel and TFF Enterprises)
  
• multiple-select track edit (like Emplode)
  
• download MP3's off of your Empeg
  
• much prettier :)
  
• upgrader support on platforms that have serial comm support
  
• ... and all kinds of other little enhancements
  

It's up on http://www.sourceforge.net/projects/jempeg now and will be going up on http://www.jempeg.org soon. Daniel will be putting up a nicer OS X installer soon as well. Check it out!

JEmpeg Team

A lovely piece of work.

Now, is it just me or are the Soup views much faster in JEmplode than they are in Emplode itself ?

Being _faster_ is a rare one to hear about a Java app :) Actually, the implementation is slightly different.

In Emplode, I believe they have a background thread that updates the soup view periodically (or the thread is triggered when an update occurs).

In JEmplode, I fire change events (add, update, delete) that soup views catch and respond to appropriately (i.e. if the Artist soup sees that a node was modified, it updates the artist of the corresponding soup entry).

Theirs is probably more "friendly" resource-wise for large updates, but ours will typically be more responsive for small updates.

Is that more information than you wanted :)

Mike

Incidentally, searching and Wendy filters are not in JEmplode yet ... That's next up on my list of things to work on (searching first).

Mike

In Emplode, I believe they have a background thread that updates the soup view periodically (or the thread is triggered when an update occurs).

Something like that. It's a bit cheesy, really. We set a timer for 2 seconds. Since timers are really low priority, we don't see the WM_TIMER message until we've stopped doing things.

In the handler, we kill the timer and trigger an incremental update of the tree. This is done using a variation of a mark-and-sweep strategy.

I might lengthen the delay, because 2 seconds seems to be exactly in line with the speed with which I switch to and from applications, which means I always have to wait for the update to finish.

This isn't such a problem in release builds, but I generally run with a debug build, and walking the tree to do an update can take up to 12-15 seconds.

I considered doing this on a background thread, but then we get into locking issues, and this solution is perfectly usable.

Very cool stuff...

Though, I noticed that when I click "Yes To All" when downloading a playlist, it acts the same as clicking "Yes" in the download confirmation box. No matter what, I have to clikc "Yes" or "No"...or *something* for each individual song and playlist.

So far, that's the only thing I've seen. I'm using the Windows version, if that helps.

Oops .. you're right. We'll get that fix in the next beta.

Question. Is it compatible with both 2.0 and 1.03?

If so, that's cool because even Emplode won't do that AFAIK.

Hmm... That's a good question. There isn't any explicit support for 1.0, but then I don't think the protocol really changed that much. I only have my player with 2.0 on it... Maybe I'll downgrade to 1.0 and try.

ms

www.jempeg.org has been updated to reflect the new release. There is a drag-and-drop-install Mac OS X application version (a mere 564K download!) available from there, as well as all the InstallAnywhere web installers for the various platforms.

Enjoy!

I can't get JEmplode to find my empeg.

OS: Debian Linux (unstable) 2.4.10 kernel
JVM: Blackdown Java 1.3.1 SDK
empeg: MkII

the empeg is connected serially to /dev/ttyS0 as well as being plugged into the network and is pingable from the desktop machine.

Is there a way to specify an IP address for JEmplode...? or a serial port...?

Let me know if there is more information you need to debug...

Cheers

Kim

I'll look into it ... The first dialog that comes up has an "Options..." button that will let you specify the IP address if discovery is not working for you.

Do you have multiple network cards on this machine? Does emptool find the player?

Mike

I run JEmptool (org.jempeg.empeg.emptool.Main) succesfully on the following config:

Redhat Linux 2.4.2-2
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Empeg Mk2
One network interface

I haven't compiled the javax.comm libraries for Linux to test serial, but I did ethernet discovery just fine.

If you continue to have problems, I may give you a jar file with some more debug information in it. You can try this:

java -classpath comm.jar:jemplode20.jar:tffid3.jar -Ddebug=true org.jempeg.empeg.emptool.Main

And see what it prints out...

Mike

Well, we officially DO NOT support this :) _However_ I think we might be able to. You think there is much demand for this feature? I think I'd like to get searching and filters support in there before this if we decide to tackle it....

ms

I hadn't noticed the options box because the first dialog that pops up doesn't size itself properly on this machine for some reason and so was about 20x50 and as it was set to be unresizable I couldn't do anything with it...

I recompiled the class for that dialog to make it resizable and can now get to the options dialog... but now the options dialog has the same problem with being too small to see any of the components within it... and recompiling that .class doesn't seem to help for some reason...

only 1 network card in the machine and emptool finds it fine...

I might try and see if I can get a way to pass in an IP address from the command line to see if it is just a GUI problem...

Cheers

Kim

I might try and see if I can get a way to pass in an IP address from the command line

IIRC you can do that from jemptool but not jemplode (although this may have changed with v2)...

java org.jempeg.empeg.emptool.Main xxx.xxx.xxx.xxx

may do the trick

-Mike

OK it must be some wierd intermittent error with my setup here cos for some reason I managed to get to the options dialog and specify an IP address this time and JEmplode found the empeg...

Hopefully it was a one off problem or something... I will look into it further if it returns... (the dialogs still open badly sized for some reason)

I will play with it more and see how things go...

Thanks for your help...

Cheers

Kim

Someone else reported the dialog size problem as well on Linux .. my Linux box runs headless, so I need to install X on there to test it out... I'll look into it. If you get a chance, can you try JEmptool and see what it does?

Mike

Thanks for the work you've put into JEmplode, Mike. It's Yet Another Great Third-Party Empeg Thing (we need something with a better abbreviation to describe these...).

On one occasion, it crashed my player during the database rebuild, and did this every time until I connected with emptool and it fsck()ed. Since then, it's worked fine for me.

It still has the problem that a lot of the dialogs are iconified and at the bottom of the window stack on their 2nd and subsequent use. This applies to the "Working...", "Tune details", "Playlist details" dialogs, but not to the yes/no/etc confirmation dialogs.

And the initial (Connect) dialog comes up 0x0, but corrects itself when I touch it. I guess this is one of the AWT bugs related to min/max size not agreeing with programmatic size, which fvwm treats differently to CDE and whatever else Sun supports. I recommend not setting the frame non-resizable until after it's showing (in the windowOpened() callback) - that works for me most of the time.

You seem to have found a workaround for the wacky insets on Java 1.3 - if you know how you fixed this, I'd like to hear about it.

Thanks for the support! Thank Daniel too -- In particular, the new ID3 parser is all his.

When you say the player crashed, can you described what the symptoms were? (i.e. player didn't restart, player hung, etc.)? I think I'm not _supposed_ to be able to crash the player, so this may be a bug to report to the Empeg guys (depending on what exactly you saw)

I'm going to look into those dialogs tonight ... Curious that the Yes/No dialog is not iconified -- I'll look at the Swing source code and see what they do. Honestly, there's not much reason to ever make the dialogs non-resizable -- I might just leave them resizeable all the time.

I didn't do anything specifc about insets -- I haven't seen any wackiness with them on 1.3 (on Win32 or OS X). Let me know which insets you've had problems with and I'll see if I did anything special ...

ms

In reply to:

---

Thanks for the support!

---

I just wish I had made time to support with actual code...

In reply to:

---

When you say the player crashed, can you described what the symptoms were? (i.e. player didn't restart, player hung, etc.)? I think I'm not _supposed_ to be able to crash the player, so this may be a bug to report to the Empeg guys (depending on what exactly you saw)

---

During the "Rebuilding databases" phase, the empeg's front panel froze, and a register dump appeared on the serial (maybe it was a kernel panic, rather than a player crash). I had to power-cycle the player to get it back; I also killed and re-started JEmplode (which was still waiting for the player to respond). Each time I tried to connect, JEmplode hung during "fetching databases" and the player crashed in the same way. But when I connected using emptool, it did a media check (fsck); all the changes I'd made had appeared. I exited emptool and from then on, JEmplode worked fine.

All the above is from memory; if I see it again, I'll record the output and report it properly.

In reply to:

---

I'm going to look into those dialogs tonight ... Curious that the Yes/No dialog is not iconified -- I'll look at the Swing source code and see what they do.

---

It occurred to me that perhaps the problematic dialogs are being re-used and the other ones are created anew each time? But I haven't read the source yet, so you'll know better than I do.

In reply to:

---

I didn't do anything specifc about insets -- I haven't seen any wackiness with them on 1.3 (on Win32 or OS X). Let me know which insets you've had problems with and I'll see if I did anything special ...

---

The problem I get occurs only on X11, and only with fvwm as window manager. What happens is that some windows (in JEmplode 1, it was the "tune properties" and "playlist properties" dialogs) get huge insets, so only a portion of the content is visible, and the rest appears obscured by a grey border. In JEmplode 1, it was usually the top half or so that was obscured, meaning that I had to stretch the dialog to about 2000px tall to edit the song title. It's been okay for me so far in JEmplode 2, so I thought you might have actively addressed it. I spent a day or two hunting for the cause in the ReparentNotify handler in awt_TopLevel.c but couldn't follow it well enough to find the cause or any workaround.

Sounds like there might be two problems .. The first is that the player crashed, which I have seen some people discussing on the Empeg beta mailing list. The second problem is that JEmplode couldn't recover. That's the more curious. I wish there were a way to freeze database state so you could send me a copy of a messed up database to test against. Oh well... If it happens again, send me the exceptions that JEmplode prints out (run it with debug=true).

Mike

Kind of funny (though annoying) bug about the insets problem ... I don't remember doing anything specifically to fix that, though I rewrote some of the code for those dialogs, and must have fixed it by accident. I believe I am reusing dialogs, too, for those ones you mentioned.

Mike

Okay, I'll do that.

Thanks.

You said you've worked around the dialog size issues before -- If I don't call setResizable at all, will the dialogs be the correct size? (I haven't setup X yet to be able to easily test on my machine)

Mike

In my experience (sorry, but I don't feel like promising anything today ), if you don't use setResizable, then windows will appear at the correct size.

The gory details:

In X, the Inter-Client Communication Conventions Manual (ICCCM) specifies that 'normal' clients can tell the window manager their minimum and maximum size, as well as their desired size. When you call setResizable(false), AWT adds the properties for minimum and maximum size, setting them both to be the same as the desired size. When you subsequently call setSize(), either directly or via something like pack(), AWT sets the desired size but doesn't touch the minimum and maximum. This means that there's a contradiction between the requested and permitted sizes, and different window managers deal differently with the conflict. Some disregard the constraints and others, including fvwm, disregard the invalid size.

If you call setResizable(false) after the window is showing, and don't subsequently resize it programmatically, then the constraints are in agreement with the requested size, and everything is okay.

I'm not sure if the problem of the connection frame appearing as 0x0 is related to the same problem, but it's possible.

I tried Jemplode 2.0 on Win32 (no shame ..).

I found it very good espescially the download utility.

Someone on the BBS already said that the confirm dialog box doesn't work when you choose yes to all.

You have to confirm for every file but it's even great.(almost backup..)


I noticed also that after using JEmplode and want to connect to empeg via Tera Term, i cannot connect to Empeg via serial.

I haven tried the Upgrade tool.

All the rest is GOOD.

PS: I would like to add a wish.
With the GRab Empeg Sreen tool , is it possible to save the grab in a file , in format bmp or Jpeg ?

With the GRab Empeg Sreen tool , is it possible to save the grab in a file , in format bmp or Jpeg ?

In Windows, the PrintScreen key captures the current screen to the clipboard. Pressing Alt+PrintScreen captures the current active window to the clipboard.

From there, you can paste the clipboard into any graphics application.

Thanks ... The confirm box is actually already fixed. It will be in the next build.

Were you using JEmplode over Serial? What exactly happens when you try to connect via Serial after JEmplode? If you power cycle your Empeg can you connect Serial again?

For saving to a gif/jpg, I just need to track down an opensource Jpeg encoder -- should be pretty easy to do.

Mike

After using JEmplode 2.0 , I tried to connect to Empeg via serial with Tera Term and when I tried to enter dev mode with q key, the player didnt swith to shell.

It didnt even display 'q' (in terminal screen ) when typing.

Nothing to do , I had to Off the player then I could use shell.

Oh, for the jpeg saving , many Thanks !!!!!!!