Bugzilla – Bug 15860
Tiny SC shutdown breaks access to MSB.com
Last modified: 2010-09-13 11:56:47 UTC
Since Fw 8637 this I have been experiencing poor response connecting to MSB.com features after having once run and shutdown Tiny SC. Steps to replicate Perform a factory reset and set up the touch. Select and play internet radio or other MSB.com (plays okay) Insert SD card or USB stick. Wait for Squeezebox server to start. Select Squeezebox server status. Wait for scanning media to complete. Select and play content on inserted media (plays okay). Select and play internet radio (plays okay) Eject SD or USB card to shutdown TinySC. Receive message there is a problem connecting to MSB.com try again. *1 Attempt to play internet radio or other MSB.com application. Get a frozen Spinny or continuous spinny. I have had a touch spontaneously recover after approx 5-30 or longer. However a factory reset is a faster path to recovery. *1 You cannot make a safe eject of the media at this point.
If you can't make a safe eject, then don't just pull it. You've been warned not to do so when you inserted it. If you still do, then expect many kind of oddities, up to data loss.
That said - do you see the same or similar problem if you cleanly unmount the media?
fw 8649 You cannot cleanly un-mount the media!!!! Also even if you do not remove the SD card after the request to eject fails, you still get the issues MSB.com functions I have discovered that the only recovery path to get MSB.com functions working again is a Factory reset. I recall there was a bug awhile ago where you could not play MSB.com content after ejecting and it was fixed but it seems to have come back but worse.
Ryan, what did you mean by: "I have had a touch spontaneously recover after approx 5-30 or longer."?
I have been unable to reproduce the specific problem of it giving a forever spinny trying to connect to mysb. After ejecting the SD card, my first action results in a spinny which times out after 20s. The resulting "Problem Connecting" menu offers me the following choices: Try Again, Switch Library, Go Home, Choose Player. Switch Library is only presented if other compatible SbSs are available. At least in my case it is inoperative (fails - just flashes and does not bring up a new menu when selected). I have a fix for this. Go Home takes me to the home menu, from which I can select Internet Radio and, when I try to go deeper, I get prompted to connected to mysqeezebox.com. This works. The 20s spinny could fail more quickly. I have a simple fix for that, using the same fail-fast mechanism as for ChooseMusicSource.
Created attachment 6642 [details] Patch for connection fast-fail
Created attachment 6643 [details] Patch for Switch Library problem
Created attachment 6644 [details] Patch for Switch Library problem
Created attachment 6645 [details] Patch for Switch Library problem
fw8652 It still gets stuck after removing the SD card. In reply to the question. What did you mean by: "I have had a touch spontaneously recover after approx 5-30 or longer."? When I have persisted to try to get a unit to connect to MSB.com content by reinserting an SD card power on reset etc. or retry playing internet radio multiple times I was able to eventually get a unit to become responsive again. This happened more than once. The 5-30 minutes was a guess of how long the unit was un-responsive. I should have said 5 and 30 minutes. I also had one begin working after it had been left in an idle state not trying to connect or play anything for a very long time. Since fw 8649 I have not been able to recover one without a factory reset.
On the subject of the core problem raised by the bug report, I have not yet found the cause. On one occasion we had SN service instance on test.mysqueezebox.com in a state where it: * had an (apparently) active TCP connection to the player; * this connection was reflected internally in the %Slim::Networking::Slimproto::sock2client structure; * Slim::Player::Client::clientCount() returned 0 and it generally appeared that the instanced did not think that it really had an clients connected; * no Slimproto heartbeat polls were being sent out - if they had been then the other end of the TCP connection would have been discovered to have been closed; * the SN database had the player registered as connected; * the player had no active Slimproto connection to any server; * test.mysqueezebox.com Comet was reporting the player as connected. Cumulatively, this set of conditions led to an irrecoverable situation with respect to connectivity to SN. Andy and I have examined the relevant code and cannot see how this set of conditions could have arisen. I can only speculate that such a situation was responsible for Ryan's original problem.
The Client::forgetClient method does not force the Slimproto TCP connection to be closed, if it is not already closed. This means that the %sock2client entry is not deleted. If SDI::Service::Heartbeat::report_status() happens to run before the Slimproto disconnect from the player arrives, then it can reinitiate the connected status in the DB, via SDI::Service::Model::Player->verify_connected() using the contents of %Slim::Networking::Slimproto::sock2client as the indication of the connected clients. The only way that SDI::Service::Control->disconnectClient() can be called, which removes the connected status from the DB, is via SDI::Service::Player::SqueezeNetworkClient::forgetClient(). Ordinarily this would be called by Slimproto::slimproto_close() when the TCP disconnect actually comes in but a check in Slimproto::slimproto_close() will not do this if the player has already been forgotten. My guess is that the correct thing to do is to call Slimproto::slimproto_close() from Client::forgetClient().
Created attachment 6658 [details] Patch for connection disconnect
== Auto-comment from SVN commit #30383 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=30383 == bug 15860: Tiny SC shutdown breaks access to MSB.com Force close of Slimproto connection when forgetting client.
== Auto-comment from SVN commit #30384 to the slim repo by ayoung == == https://svn.slimdevices.com/slim?view=revision&revision=30384 == bug 15860: Tiny SC shutdown breaks access to MSB.com After issuing a clientConnectCommand, give player time to have output queue flushed and disconnect cleanly before forcing a client-forget.
== Auto-comment from SVN commit #8658 to the jive repo by ayoung == == https://svn.slimdevices.com/jive?view=revision&revision=8658 == bug 15860: Tiny SC shutdown breaks access to MSB.com Fix problem with Switch Server menu after failure to contact current server.
== Auto-comment from SVN commit #8659 to the jive repo by ayoung == == https://svn.slimdevices.com/jive?view=revision&revision=8659 == bug 15860: Tiny SC shutdown breaks access to MSB.com Fast-fail when current server is discovered to be unavailable rather than wait for 20s timeout.
fw 8660 fw 8660 I just tested this multiple times on multiple units and have been able to perform MSB.com functions after SD card ejection okay. This was with a unit operating independently. That is not serving any other device, or synced to any other device. A bit slow sometimes, but much better than it was.
*** Bug 15941 has been marked as a duplicate of this bug. ***
This bug has now been fixed in a released version of the Squeezeplay firmware (SB Touch, SB Radio, and SB Controller). If you are still seeing this bug, please make certain you are running firmware 9009 or higher, and re-open it. Thanks!