Had this problem with 42-pre5, so I upgraded to 42.

I set a wendy flag on one song, and make no other changes, then sync.

The status indicator bar window pops up, says "Locking Player Interface", then nothing. JEmplode no longer refreshes the screen, either. The player eventually gives up, per the serial port output:
server_protocol_handler.cpp:1383:Timeout during synchronise, restarting player

And in fact I then have to resynchronize to get a useful database...

I figure I'm going to have to look at this, but I was wondering if anyone had ideas. I think I'm going to sleep now.

Dont know if it can help but I had problem to sync my player but Error Message was 'Media Error' player rebooted and could not sync my player.

I stopped the applications daemon launched by preinit and then no error.

Can you consistently reproduce this?

Can you consistently reproduce this?

Very easily. I backed out to non-ext3. I suppose I can disable gpsapp and launcher, but i can sync songs to it, just not set these wendy flags, so that seems sort of an odd manifestation.

Definitely weird ... what if you change another tag at the same time? What if you JUST change title, and not wendy? Just trying to narrow the problem down .. curious if it's only when you ONLY sync tags with just wendy changed .... There must be an error that's being swalled somewhere...

I tried changing other tags and the wendy and lost, I can try some other things, but the cycle time on this is like 30 minutes, because the player app times out, builds a database inline, then i reconnect with jemplode and it has to rebuild the database, so it's tedious. i'll try it this evening, after i get home, if you have a larger list of things to try, i'll try as many as i can before i sleep

Picked same song, changed comment and set a wendy flag. "Synchronize" and it's gone, just like before. I'll try again in 30

If you can just do one last one where you just change a comment and sync, that's all i need ... just curious.

And of course now I remember why I had ext3; I need to not pull power on the player to get the app to restart when this happens. Sigh.

Ok, as soon as it's back I'll change a comment in the same song, and sync.

Changed just a comment, on the same song, and lost the same way.

Perhaps of some significance, perhaps not, is that I selected the song from the result in the large pane of a search for "marked=yes"

I intend to test this theory, but not until I play games with my cable company.

I'm doing this on 42 on my Win2k box and it's working fine ... What OS and Java VM version are you using?

Started life as RedHat Linux 7.2, java is
java version "1.3.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)

I haven't gotten back to experimenting and figuring out what's going on.

I suppose I should look into the possibility of an interactive java debugger, because while I don't know Java I don't think I'm quite so slow that I couldn't figure it out, if I had a way to watch what was going on.

when 43 goes up, put jempeg.debugLevel=24 in your .jempegrc and try again ... this should print debug output to your console (you might have to run it java -jar jemplode20.jar to see this output)

Mike

Ok.

Added that, ran java -jar...

Last thing I see looks like it was too early.
at org.jempeg.empeg.emplode.dialog.ConnectionSelectionDialog$RefreshRunnable.run(ConnectionSelectionDialog.java:303)
at java.lang.Thread.run(Thread.java:484)
1035741798755: Checking root playlist...
1035741798756: Starting tree->Repair() recursion...
Attaching: [FIDPlaylist: tag:source; fid = 2064; childCount = 943]
Attaching: [FIDPlaylist: artist/album; fid = 98976; childCount = 365]
Finished org.jempeg.empeg.soup.SearchSoupUpdater@3957ea in 597ms
Finished org.jempeg.empeg.soup.BasicTagSoupUpdater@34be3d in 3665ms
Finished org.jempeg.empeg.soup.BasicTagSoupUpdater@35bb0f in 4012ms
Finished org.jempeg.empeg.soup.SearchSoupUpdater@73305c in 12710ms
Finished org.jempeg.empeg.soup.SearchSoupUpdater@6c1a82 in 12311ms

And then it's hung.

I guess I'll try updating to Java 1.4, "just in case".

No dice. Tried selecting from a playlist instead of a search, and tried Java 1.4. Still lose.

I guess I'll try to figure out how to debug java now.

It looks like there is some output cut off here ... can you make sure you have the full stack trace and exception name? probably run java -jar jemplode20.jar > output.log and put the contents of output.log up for me to take a look at.

Thanks
Mike

Does this happen only on one particular song or on any single song?

I can try a different one, but I've been trying the same one.

Different song, still lost.

I can put it on the network for real if you think it will help. Otherwise I'll find a debugger eventually.

Can you do the same thing but change jempeg.debugLevel to 31?

The last thing I see is now:
1035760250941: SocketConnection (1398720): close
1035760256120: FIDPlaylistDatabase contains 23380 entries
1035760256136: FIDPlaylistDatabase maxFID = 204016
1035760256249: Ended up with 23380 of 23380
1035760256592: SocketConnection (11742932): close
1035760256605: Checking root playlist...
1035760256606: Starting tree->Repair() recursion...
Attaching: [FIDPlaylist: tag:source; fid = 2064; childCount = 943]
Attaching: [FIDPlaylist: artist/album; fid = 98976; childCount = 365]
Finished org.jempeg.empeg.soup.SearchSoupUpdater@1c18a4c in 566ms
Finished org.jempeg.empeg.soup.BasicTagSoupUpdater@19e09a4 in 4805ms
Finished org.jempeg.empeg.soup.BasicTagSoupUpdater@8aeed0 in 5236ms
1035760263664: TableModel org.jempeg.empeg.model.FIDPlaylistTableModel@45e228 is now listening to [FIDPlaylist: search:(marked); fid = 304; childCount = 707]
Finished org.jempeg.empeg.soup.SearchSoupUpdater@c3e82b in 15948ms
Finished org.jempeg.empeg.soup.SearchSoupUpdater@1bf7b23 in 16120ms
1035760287555: SocketConnection (11742932: actually open

That's not cut off, either. That's the last thing it prints.

I figured maybe jswat would help. And, I got as far as loading the database, but couldn't actually trigger the problem before jswat died:
java.lang.StringIndexOutOfBoundsException
at java.lang.StringBuffer.deleteCharAt(StringBuffer.java:650)
at com.bluemarsh.jswat.PathManager.setSourcePath(PathManager.java:478)

(and so on)

I hate Java.

Blame jswat, not Java OK .. One last time, we'll get really picky and set debugLevel to 32 -- this will do the full debug output of the protocol... Can you put the whole output log up for that too? Sorry to have you keep doing these .. they're not telling me much, unfortunately. ms

Well, yes, I gathered the logs have been pretty useless.

Surely this can't be right. After the database rebuilds I'm going to try again.

Nope, it's reproducible.

jdb is too crude. jdebugtool seems to have hung after starting the JVM. At least jswat run for a while before it blew up. How can I not blame Java when as a novice every debugger I try just wants to taunt me?