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 !!!!!!!

Did you happen to notice if your player was frozen? Could you do anything through the normal player UI?

Mike

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

This is known.

It's actually mentioned in the corresponding FAQ section.

Hey Mike, can you put up a plain .jar file please? I don't want to use the InstallAnywhere stuff. I have had too many bad experiences with it.

Thanks,
-Mike

Here's the serial output when it fails at restart:

player(118): memory violation at pc=0x02078f34, lr=0x020f6fc8 (bad address=0x0000001c, code 2)

pc : [<02078f34>]    lr : [<020f6fc8>]

sp : be5fbb08  ip : be5fba80  fp : be5ffcb8

r10: 00000001  r9 : 00000005  r8 : 02244af0

r7 : ffffbea0  r6 : ffffbea4  r5 : be5fbb10  r4 : be5fbb34

r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : 00000000

Flags: nZCv  IRQs on  FIQs on  Mode USER_32  Segment user

Control: C0EC917D  Table: C0EC917D  DAC: 00000015

Function entered at [<02078dbc>] from [<020785b8>]

 r10 = 00000001  r9 = 0219ADAC  r8 = 0219AC50  r7 = BE5FFCC0

 r6 = 0219ACF0  r5 = 0219ADAC  r4 = 02244AF0 

Function entered at [<02078424>] from [<02076a94>]

 r7 = 022423F8  r6 = 0219ACF0  r5 = 022423E8  r4 = 0000000C

Function entered at [<02076830>] from [<020ec52c>]

 r10 = 020EC474  r9 = 0219AC50  r8 = 0000280B  r7 = 00000080

 r6 = 0000000B  r5 = 0219AC50  r4 = BE5FFD64 

Function entered at [<020ec474>] from [<020f3808>]

 r5 = 0219AC68  r4 = BE5FFE40 

Function entered at [<020f3740>] from [<0212e80c>]

 r4 = 00000000 

Function entered at [<0212cf80>] from [<020f3584>]

 r8 = 0219712C  r7 = 02197118  r6 = 020EC474  r5 = 00000003

 r4 = 00000000 

Function entered at [<020f34d4>] from [<0212e80c>]

 r5 = 00000000  r4 = 00000000 

Function entered at [] from [<00000000>]

Function entered at [] from []

Function entered at [<23a0fef4>] from [<23a0ff00>]

Unable to handle kernel paging request at virtual address 23a0fef8

memmap = C0EC8000, pgd = c0ec8000

*pgd = 00000000, *pmd = 00000000

Internal error: Oops: 2

CPU: 0

pc : []    lr : []

sp : c0293f44  ip : c0293f00  fp : c0293f90

r10: 00000002  r9 : c0fa80e0  r8 : 0000000c

r7 : 00000000  r6 : 23a0fef4  r5 : 23a0ff00  r4 : e3a02000

r3 : 60000013  r2 : c00fe1e4  r1 : 00000001  r0 : e3a01ff0

Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user

Control: C0EC917D  Table: C0EC917D  DAC: 00000015

Process player (pid: 118, stackpage=c0293000)

Stack: 

c0293f20:                                               c0019670 c00dfb60 60000013 

c0293f40: ffffffff c0fa80f8 c0fa3920 c0292000  c0293fb8 0000001c c0011948 020f6fc8 

c0293f60: 0000001c 00000002 c0293fb8 0000000f  0000001c 00000000 00000002 00000005 

c0293f80: 00000001 c0293fb4 c0293f94 c0011e80  c00116f8 c00fc978 be5fbb10 ffffbea4 

c0293fa0: ffffbea0 02244af0 00000000 c0293fb8  c000a008 c0011da8 00000000 00000000 

c0293fc0: 00000000 00000000 be5fbb34 be5fbb10  ffffbea4 ffffbea0 02244af0 00000005 

c0293fe0: 00000001 be5ffcb8 be5fba80 be5fbb08  020f6fc8 02078f34 60000010 ffffffff 

Backtrace: 

Function entered at [] from []

 r10 = 00000001  r9 = 00000005  r8 = 00000002  r7 = 00000000

 r6 = 0000001C  r5 = 0000000F  r4 = C0293FB8 

Function entered at [] from []

 r8 = 02244AF0  r7 = FFFFBEA0  r6 = FFFFBEA4  r5 = BE5FBB10

 r4 = C00FC978 

Code: ebfce63f e2440010 (e5961004) e1a035a1 e59f20cc 

Restored terminal settings

Remounting first music partition read-only

Remounting second music partition read-only

No secondary hard disk

Abnormal player termination

Player received signal 11

Starting player

empeg-car 2.00-beta3 2001/10/17.

E !! tags.cpp            61: Failed to open tags (0xc0041002).

Rebuild 71194ms

For people who are annoyed by the couple of bugs that have been reported so far, you can grab a replacement jemplode.jar -- This is a little more "unofficial" -- Once we get a couple larger features in, we'll do a "real" 2.0b2 with all the fanfare of installers.

http://www.batmanthehorse.com/jemplode/jemplode20.jar

Just replace jemplode.jar with this in your install directory (or you can actually run this standalone with java -jar jemplode20.jar).

Mike

Hey Mike, is this "unofficial" jemplode release still floating around somewhere? Am trying to use jemplode under Mac OS X 10.1, and it is a little flakey. Thought that the newer jar file might help, but I can't get to it anymore ...

It should be at the same place -- I just went to

http://www.batmanthehorse.com/jemplode/jemplode20.jar

and it downloaded .... When you say "flakey", can you describe what you're seeing?

ms

Just managed to grab it, thanks! Last night I was getting a 404 error message. Wierd! The "flakeyness" I've experienced consists of: Syncs failing with "media check failed" messages. i.e. nothing gets loaded across. The only way to sync successfully way to remove power from the empeg (even though jempeg had performed a soft boot that wasn't enough) and restart jempeg. The GUI hanging or going REALLY slowly. This would mainly happen after a sync (I took to restarting everything after every sync), but I had it happen a couple of times before a sync. Seemed to be caused by switching to another application and then back - OmniWeb if I remember correctly, but I can check it for you. Had to be real patient waiting for the sync button to come up so that I could save my changes. Sometimes the whole jempeg window would go completely grey, or wouldn't update, and I would have to switch to another program and then back to get the screen updated - the GUI would still be sluggish, but at least I could see where to make the next click :-) Would sometimes block the whole machine! That's as good as I can remember it this morning anyway. Would be happy to test it further for you. I think doing a drag and drop operation may have triggered the GUI funnyness before a sync. Hmmm. Is still GREAT being able to load stuff across on my Mac. I can stoop to using a Windoze box at work to tidy up tags and playlists (was too annoying in jempeg last night). Oh, one other thing I noticed, genres are often comming across strange (numbers in brackets instead of tags) and I have been getting -1 for the year quite often too. Maybe I should fix the tags in iTunes first and see how it behaves then ... Anyway, thanks again for the quick response :-)

Thanks for all the details ... Mike Comb reported some of this stuff on OS X as well. I'll break out the OS X laptop and start doing some more testing to see if I can track down what is going on.

Thanks Derek --

Mike

No worries. Actually I tried out the new jar file this morning before I came to work and it seems to be a LOT better. I could sync and jempeg was still quite useable afterwards. Nice :-)

Interesting .. I didn't really do that much to change stuff, but that sounds great :) I wonder if it was a weird artifact of the 0x0 pixel windows? Oh well, keep an eye out for those other problems and let me know which ones are still there ... I suspect all the genre and tag related stuff is still there, since that hasn't really changed.

Mike

Mike Comb reported some of this stuff on OS X as well

Yep, that all sounds pretty familiar. I believe Dan Z promised to come up with a work around for the year bug although it is actually a problem with the tag (there is an ID3 year tag there, but without any content). Are the sources for the ID3 package available somewhere? If so I could probably fix that one myself.

As far as the GUI slowness (ArrayIndexOutOfBounds exception) I just tried again and that does seem to be fixed with the updated version. I had not tested it before since you said you hadn't had time to look at it. Maybe it is related to the updated progress dialogs? BTW, the problem I reported where the dialogs don't always go away under FreeBSD seems to be happening under OS X as well.

-Mike

As far as the GUI slowness (ArrayIndexOutOfBounds exception) I just tried again and that does seem to be fixed with the updated version.

Uhhh, nevermind. It just happened again. It was fine for half a dozen test syncs, but as soon as I deleted all the test files I had synced and tried to sync one more time I got this problem again.

-Mike

In reply to:

---

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.

---

Seems to be fixed in JEmplode 2.0b11.