jemplode: sync goes into la-la land?

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?

jswat 2.9 (as opposed to 1.6) seems to be a bit better.

Thread AWT-EventQueue-0 seems to be in PlayerDatabase.getConfigFile(), status monitor

Thread jEmplode: Synchronize is in Component.enable(), status monitor

Threads DestroyJavaVM, AWT-Motif and Signal Dispatcher are in status Running, and everything else is in status Wait.

I'm still trying to figure out why JSwat 2.9 isn't showing source when 1.6 did, so maybe I can figure out what's going on.

I use Eclipse which has a really nice debugger in it (www.eclipse.org) ...

I tried Eclipse, and it seems to be pointing exactly the same places.

Synchronize is in javax.swing.JButton(java.awt.Component).enable() leading back up through awt and swing to org.jempeg.empeg.emplode.dialog.ProgressDialog.setStopEnabled() (line 161)

It would be neat if I could figure out how to export the stack backtraces.

I guess I'll start reading source.

I suppose I can do it by cheating

and by cheating some more, since it's so long.

The thing I don't understand is how the line number for the getConfigFile() call can be right; How can it hang comparing a variable to NULL?

Those jpg's aren't working By the way -- about the debugLevel 32 -- I was wrong, 31 was supposed to be showing everything but I commented out the lowest level debugging code to increase performance... Try doing this: after it hangs, go to the console and hit either Ctrl-Shift-Break or Ctrl-\ and see if it prints all the stack traces to the console. If you can, save those and send them to me.... It's frustrating because on my RedHat 7.2 everything is working fine (running over X11 since I don't have X installed on it).

Well, I put the jpgs in my web directory, so:
http://www.dementia.org/~shadow/grab1.jpg
and
http://www.dementia.org/~shadow/grab2.jpg

I'll try that now, though.

No dice. Break is fn-pause on this by that shouldn't matter.

Eclipse has a "copy stack" function if you right-click a thread, but I haven't yet figured out how to do something with that copy.

Actually, I created a simple text file resource and could paste into that. Annoying that eclipse won't play nice with the X11 clipboard.

Cool .. I actually could see this from your jpgs too ... Apparently there's a deadlock trying to retrieve the value of your wendy flags at the same time as synchronizing (both methods are blocking on the same object). Is it possible you have Wendy flags as a column in the right-hand pane (the playlist table view)? Try removing that column and see if it still locks ... I'll try to fix the locking tonight so you can have that column on.

Thanks a lot for getting those stack traces ...

Mike

I might add that you also now have Eclipse installed, and it's pretty much hands-down the best Java IDE around. So there's a bright side to everything

The sync in the text log was a change of a comment and not a wendy flag, but seems to cause the same thing.

Yes, I have the wendy flags in a column, I'll try disabling that.

Thanks a lot for getting those stack traces ...
Thanks for writing it, and looking at it, and...

Eclipse looks pretty cool, I just haven't figured out how to build the jar file successfully yet.

I installed eclipse in /usr/tmp, which doesn't get auto-cleaned, but I should probably do something more permanent.

Indeed, removing the Wendy column brings joy. Thanks!

I guess now I'll slap together a new gpsapp for Tony with the cold start fix, since I put it off all weekend.

I guess now I'll slap together a new gpsapp for Tony with the cold start fix, since I put it off all weekend.

So I think fact that you're changing a field isn't actually the problem, but rather the AWT painting thread just happens to be blocking trying to get the wendy flag value to draw it on the screen in the table ... Very weird.

Yeah, that's... neat.

But still, turning off the wendy column makes it all good, so I could finally flush my changes. Still can't bulk unset "marked" but jaharkes alleged jemplode 41 could, and I'm could to try that later.

I didn't look at bulk setting marked for 43 .. i'll see if I can get that in 44 ...

Still can't bulk unset "marked" but jaharkes alleged jemplode 41 could

Didn't work for me, nor did jemplode 34. I guess I'll wait for 44, or create a playlist of marked tracks and unmark them by hand.

At least I can sync my Wendy flags now, though.