Bugzilla – Bug 2705
SB3 player hang/lockup when using >>/<< buttons in web UI
Last modified: 2006-02-15 12:54:20 UTC
On my SB3 wired unit, a hang/freeze/lockup happens (very reproducible) if I: 1) start playing any MP3 2) hit >> (ffwd) in web UI (fishbone), wait a few seconds 3) hit << (rev) in web UI (fishbone), wait a few seconds 4) hit play in the web UI The player is now hung: display is frozen, the SB does not respond to ping, holding power button on remote for 5 seconds does nothing. Restarting slimserver does not help - it just comes up and displays the message that no player can be found (since the SB3 is not responding). I have to remove and restore power in order to unfreeze it. Note that not all Web UI skins have >> and << (hence the fishbone example). Also, using the physical remote to try the same thing does not cause a hang. If done with a FLAC file, the SB3 does not hang, but it does not resume play after step 4 above. For my tests, I was Using slimserver 6.5b1 - 5376 - Linux - EN - utf8.
*** Bug 2706 has been marked as a duplicate of this bug. ***
HTML/Fishbone/status_header.html. change lines 156 & 157 to read: [% PROCESS playctl command='p0=button&p1=rew.hold' width='30' height='19' img='rew'condition=rate == 'rew' -%] [% PROCESS playctl command='p0=button&p1=fwd.hold' img='ffwd' condition=rate == 'ffwd' -%] see if that helps at all.
KDF, I can try this - were you able to reproduce? But if these changes help, it's a workaround, not a fix. The SB3 should never lock up - if it does, I consider that a firmware or hardware bug. I am changing the properties of this bug back to what I had before for now.
ok, nevermind then. thanks!
KDF - not sure what you meant by the last comment... BTW, it may be that your proposed change to the Fishbone code is the right thing - looks more correct than before.
I mean that since you seem to have the cause all decided, I'll just leave it to you and dean. I can't reproduce this, since I'm not at home (at my day job actually). However, since you have decided what the problem is, I'll leave my "workaround" and you and Dean can sort it out. Nevermind means, don't mind me. I wont bother you with more, becuase I'm going to spend my time elswhere now. Thanks for the feedback. Good luck :)
Hi KDF, Workarounds are good, and as I said, I think if your change to the skin avoids the issue, it's a valuable change, especially if it is a more correct action to take when hitting the button (which it does appear to be). Maybe I read your comment wrong, but it sounds like you might have taken offense to my post - perhaps my tone did not come across well. I meant no offense, and emails/posts, etc. can be like that sometimes. Back to the bug, I think that perhaps your skin found a way to lock up the SB2 (and probably the SB2 as well). It's my opinion that anything that can cause hung hardware is uncovering a firmware or hardware issue, and if so, the firmware guys at SlimDevices probably would want to take a look; that's why I wanted to leave the bug open on that component. I am not qualified to determine the actual problem (and the firmware source is not public anyway), but I did find that the solid hangs were reproducible. Also, who knows what other actions could cause the SBs to hang in the same manner. Even if workarounds are found, it's better not to let lurking bugs slip through the cracks if they can be addressed directly. That said, I'd rather have your workaround in the skin, assuming it helps, so I will test it, and I encourage you to submit the change if it works around the hang.
fishbone skin corrected in trunk and 6.2.2 branch at change 5404. since a workaround is now in place, this drops from critical (see https://bugs-archive.lyrion.org/page.cgi?id=fields.html#bug_severity). Summary likely needs to be reworded to reflect the outstanding issue, but I'm not up for suggesting anything at this time.
*** This bug has been marked as a duplicate of 2463 ***