Can somebody help?
I am getting an error at the end of installation V47, as soon as I click done it gives me this error.
Wjview.exe application error
The instructions at "ox77f52610" referenced memory at "oxo4993db0". The memory could not be "written".
Click on ok to terminate the program.
But version 45 works with no problems? Also I have tried v47 on my laptop and it works fine. Running XP on both.

wjview.exe is Microsoft's Java VM, I believe ... Make sure you have java installed from www.java.com and try again, maybe?

Mike,

Do you have just the Mac OS X binary that you can post? The install.zip consistently crashes on my machine after the "Choose Alias Folder" screen.

I've got 10.3.1. Have you run the installer successfully on that version? If not, is there any sort of incompatibility between InstallAnywhere and this version or something?

FYI, In trying to solve this problem, I tracked down my backup of 10.2.8. The installer actually works on that, so I think there must just be some InstallAnywhere problems with Panther, or else something's really screwed up on my system since the upgrade.

It installs on my Panther, so it's not Panther-specific ... When I do the next build I'll do a zip also.

I've found a small bug in jEmplode 47. When selecting new playlists or soups the status bar doesn't automatically update the total track count for the playlist. If you do a "select all" though, the status bar does update itself.

This may just be a problem using my Sun 1.4.2 JavaVM in Linux.

Ross

If you just click on anything on the right side, will it update, or do you have to do select all?

I think I may have found a small issue.. (Didn't see it mentioned in any thread here..)

Fresh, FRESH install of 3.00a3. There was no CONFIG.INI file. (Causing Emplode 2.01 to crash.) Fill out 'Player Config' in 47. Sync. *STILL* no CONFIG.INI file. Even right after clicking the 'Save/Sync' button, when try to exit, get the message "The Database is not in sync.." message. Never would sync up new config.ini. So first issue - no new config.ini if missing. (Maybe a bug in actual player? But no, because..)

Loaded up 44, made CONFIG.INI perfectly fine. Re-run 47, loads config.ini fine. Still won't save anything.. :/

I like the sync and continue working function, however! Very smooth! It'd be nice to have a little textbox type window with a status bar, so you can see past activities.. Instead of having just a small line telling you..

Good job!
Me.

So basically 47 neither adds nor updates config.ini?

Yeah, clicking on a track on the right-hand side so that something is selected will cause the status bar to update. Basically you just need to have something selected before jEmplode will tell you the total number of tracks in the list. Whereas jEmplode 44/45 would update the status with the total number of tracks in the list whenever you click on a list in the left-hand panel.

Ross

I can confirm that that jEmplode 47 isn't updating the config.ini file. It does read the file, but it doesn't update any changes after a sync.

Ross

What he said.
Of course, I'm testing on v3.00a3. Have not tested on v2.00..

Me.

Does anyone have any ideas as to what I should check to fix this issue?

If you run from the console (java -jar jemplode.jar) do any errors get printed out?

ms

Post deleted by sirmanson

So nothing prints out to the console? How about running it

java -Ddebuglevel=31 -jar jemplode.jar

and mail me the output -- [email protected]

ms

Here is the output :
Unable to open connection to device. caused by:
org.jempeg.music.protocol.ConnectionException: Unable to connect to device using Ethernet.
at org.jempeg.music.protocol.SocketConnection.open(SocketConnection.java:132)
at org.jempeg.empeg.protocol.EmpegProtocolClient.open(EmpegProtocolClient.java:351)
at org.jempeg.empeg.protocol.EmpegProtocolClient.open0(EmpegProtocolClient.java:943)
at org.jempeg.empeg.protocol.EmpegProtocolClient.isDeviceConnected(EmpegProtocolClient.java:173)
at org.jempeg.empeg.protocol.discovery.UnicastNetworkEmpegDiscoverer.discover(UnicastNetworkEmpegDiscoverer.java:53)
at org.jempeg.empeg.protocol.discovery.CompoundEmpegDiscoverer.discover(CompoundEmpegDiscoverer.java:66)
at org.jempeg.empeg.manager.EmpegDiscoveryManager.refresh(EmpegDiscoveryManager.java:161)
at org.jempeg.empeg.manager.dialog.ConnectionSelectionDialog.refresh(ConnectionSelectionDialog.java:240)
at org.jempeg.empeg.manager.dialog.ConnectionSelectionDialog$RefreshRunnable.run(ConnectionSelectionDialog.java:310)
at java.lang.Thread.run(Unknown Source)

That's it? There's no other output?

That's all she wrote. You had me change it to use Unicast only when connecting to the empeg and now there is no output at all.

Same behavior in the UI? Just sits there at Downloading Database?

It finishes downloading the database and stops at "Updating Interface"

Can you run it from the console again, and when it gets to the point when it hangs, switch to the console and press Ctrl-Break (or on Linux Ctrl-Backslash, I think) and send me the full output ...

ms

Mike,

I just uploaded some files with 47 (nice work). I noticed that it caught the duplicates in the dialog, but strangely enough, it uploaded them dups anyways. The only reason this is somewhat bothersome is that I generated a soup called "newstuff" which only has recently uploaded material based on the create date. With 47, the duped stuff also showed up in newstuff since it was re-uploaded.

Is this pilot error?

Thanks
-Ted

thats how its supposed to work. it creates a reference to the track in the offending playlist.

That's with a regular playlist ... with a soup playlist it should use the alternate implementation which doesn't do that (you don't want multiple instances appearing in soups)

wow. i can't believe i didnt notice this. where is the Ignore as Child option in the properties of playlists? it seems to be gone in v47.

Hmm .. May have accidentally been sacrificed to the gods of shared Karma code ... I'll bring it back in the next build.

ms

May have accidentally been sacrificed to the gods of shared Karma code ...

Which would be a real shame, seeing as how the last time I checked, the Karma actually correctly honors the ignore-as-child flag in nested playlists.

Yeah -- I just didn't realize that at the time ... There were a lot of pieces to pickup after I got the Karma code working.

I just switched to jEmplode 47 (by replacing the jEmplode.jar file and adding the graphics.jar file).

Works nice, especially the updated sync method (previously I used the 44 version).

One question:
When I upload an mp3 using version 44, the tag "genre" of the file reflected the correct value (e.g. Rock).

When using version 47, new files get the full tag "(17)Rock" added (i.e. with the old ID3V1.x numerical code).

I checked the binary contents of the file, the full "(17)Rock"it is present in the file, also when I upload the file using jEmplode 44; The only difference seems to be the behaviour of jEmplode 47.

Is there any way to keep using version 47 without getting the numerical code automatically added? Or did something go wrong when updating from jEmplde 44 to jEmplode 47 on my system?

Jelle

NB: tested on SuSE 8.2 Linux system, with j2re1.4.2_01 as java engine