Bug 10443 - Failure to resume song on connection recovery after short network disruption
: Failure to resume song on connection recovery after short network disruption
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: 7.0
: PC Linux (other)
: P3 normal (vote)
: 7.4.0
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-23 09:34 UTC by quiet.dragon
Modified: 2009-10-05 14:31 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description quiet.dragon 2008-12-23 09:34:28 UTC
I was previously running squeezecenter-7.0.1-noCPAN.tgz with firmware squeezebox2_88.bin.  Using this older configuration, I noticed that the SB3
would resume playing a song after even quite serious network disruption.

This capability appears to be lost in the new squeezecenter-7.3-noCPAN squeezebox2_120.bin configuration.


I have the following network configuration:

SB3 <---> WiFiRouter1 ==== WiFiRouter2 <---> Server

The link between SB3 and the WiFiRouter1, and the link
between the WiFiRouter2 and the Server are wired Ethernet.

A microwave oven will disrupt the wireless link between the
WiFiRouters.  I believe you can achieve the same effect by
diconnecting the wired link between Server and WiFiRouter2.



I have the setting:

  powerOnResume: PauseOff-PlayOn

The following screen savers are installed:

   When playing:  RSS ticker
   When stopped:  Date and Time
   When off:      Weather, Date and Time

Some experiments with squeezecenter-7.3-noCPAN squeezebox2_120.bin:

-----------------------------------------------------
1 minute 30 second Microwave disruption

a. Play song random song mix (FLAC)
b. Player shows RSS ticker
c. Disrupt connection using microwave oven for 1.5 minutes
d. After 15 seconds the display shows

      Can't connect to SqueezeCenter
      Left to go back, right to try again

e. Song stops after 40 seconds
f. Microwave stops after 1.5 minutes
g. After about 15 seconds, SB3 recovers RSS ticker, loudspeakers click
   off then on, but SB3 remains silent.
h. Wait another minute, then power off and SB3 shows Weather, Date, Time.
i. Power on, song resumes!

-----------------------------------------------------
2 minute Microwave disruption

a. Play song random song mix (FLAC)
b. Player shows RSS ticker
c. Disrupt connection using microwave oven for 2 minutes
d. After 15 seconds the display shows

      Can't connect to SqueezeCenter
      Left to go back, right to try again

  [ Sometimes says, "Connecting to SqueezeCenter", then blank ]

e. Song stops after 40 seconds
f. Microwave stops after 2 minutes
g. After about 15 seconds, SB3 shows "Now Playing", but is silent
h. After a little while longer, SB3 shows Time Display (suggesting
   that it is stopped as per the screen saver selection above), but
i. Navigate to Random Mix shows "Playing Random Song" !
j. Power off and SB3 shows Weather, Date, Time
k. Power on, and SB3 remains silent. Navigating to Random Mix still
   shows "Playing Random Song"

-----------------------------------------------------
Comment 1 quiet.dragon 2008-12-23 09:52:52 UTC
I've just tried the same experiment with squeezecenter-7.0.1-noCPAN.tgz with firmware squeezebox2_88.bin.

-----------------------------------------------------
1 minute 30 second Microwave disruption

a. Play song random song mix (FLAC)
b. Player shows RSS ticker
c. Disrupt connection using microwave oven for 1.5 minutes
d. Song stops after 40 seconds
e. Microwave stops after 1.5 minutes
f. After about 15 seconds, SB3 recovers RSS ticker, and song continues.

-----------------------------------------------------
2 minute Microwave disruption

a. Play song random song mix (FLAC)
b. Player shows RSS ticker
c. Disrupt connection using microwave oven for 2 minutes
d. Song stops after 40 seconds
e. Microwave stops after 2 minutes
f. After about 15 seconds, SB3 recovers RSS ticker
g. After about 30 seconds, SB3 continues playing song
-----------------------------------------------------

Note that in both cases the interrupted song continues without any
manual intervention.
Comment 2 Alan Young 2009-01-11 05:03:37 UTC
If you are prepared to experiment further then it would be great if you could repeat the experiment with SC7.2.
Comment 3 Chris Owens 2009-01-12 09:41:07 UTC
see bug 7048
Comment 4 Chris Owens 2009-01-12 09:42:14 UTC
We will set it to at least teh buffer length.  Say 5 minutes, 300 seconds.
Comment 5 quiet.dragon 2009-01-12 13:02:57 UTC
(In reply to comment #4)
> We will set it to at least teh buffer length.  Say 5 minutes, 300 seconds.
> 

I'm not sure what you're going to set. Perhaps a slightly longer explanation?
Comment 6 quiet.dragon 2009-01-12 13:03:40 UTC
(In reply to comment #2)
> If you are prepared to experiment further then it would be great if you could
> repeat the experiment with SC7.2.
> 

I don't have time to do this right now. Perhaps this weekend.

Is this still a useful thing to do?
Comment 7 Alan Young 2009-01-12 23:02:48 UTC
Yes, it would still be useful. There were relevant changes both between 7.0 and 7.2 and in 7.3. It would be useful to have confirmation that we are chasing the right problem.

And to answer your other questions, there is a timeout in SC after which a player with which it has lost connectivity is "forgotten": that is, playing state etc. is discarded. This is currently 60s and we propose to increase this (to what it used to be) to 300s. The rationale is that a player may buffer up to around 3-4 minutes of audio and it seems reasonable that, if a player can reconnect within this interval, it should be able to carry on as before, which will only be possible if it has not been forgotten.
Comment 8 quiet.dragon 2009-01-13 13:45:58 UTC
(In reply to comment #7)
> This is currently 60s and we propose to increase this (to what it used to
> be) to 300s.

When did this change to 60s ?

When (which nightly build) do you think it will change back ?
Comment 9 quiet.dragon 2009-01-18 08:52:18 UTC
(In reply to comment #7)
> Yes, it would still be useful. There were relevant changes both between 7.0 and
> 7.2 and in 7.3. It would be useful to have confirmation that we are chasing the
> right problem.

I found that 7.2.1, unlike 7.3, would recover and continue playing the song after both 1.5 mins and 2 mins of disruption.

The physical test configuration was the same. I didn't configure the SqueezeCenter and SqueezeBox behaviour identically wrt plugins and screensavers.

I confirmed that:

  powerOnResume: PauseOff-PlayOn

Comment 10 quiet.dragon 2009-01-18 08:59:59 UTC
(In reply to comment #7)
> And to answer your other questions, there is a timeout in SC after which a
> player with which it has lost connectivity is "forgotten": that is, playing
> state etc. is discarded. This is currently 60s and we propose to increase this
> (to what it used to be) to 300s. The rationale is that a player may buffer up
> to around 3-4 minutes of audio and it seems reasonable that, if a player can
> reconnect within this interval, it should be able to carry on as before, which
> will only be possible if it has not been forgotten.


Given the nature of WiFi, what purpose is served by "forgetting" the player state in this way?

Would it be possible to retain such state indefinitely --- or at least until the SqueezeBox is explicitly forgotten ?


I see there is/was some discussion about the explicit "Forget Player" button being removed from the web interface:

http://forums.slimdevices.com/archive/index.php/t-49679.html

(Admittedly I can't find the button on the 7.2.1 web interface.)
Comment 11 Alan Young 2009-03-08 04:37:28 UTC
Change 25405
Comment 12 quiet.dragon 2009-03-22 09:49:27 UTC
(In reply to comment #11)
> Change 25405

https://builds.slimdevices.com:8080/parabuild/build/changes.htm?cid=1065&buildrunid=32457


I click on link to /7.4/trunk/server/Slim/Networking/Slimproto.pm:


http://svn.slimdevices.com/viewvc.cgi/7.4/trunk/server/Slim/Networking/Slimproto.pm


Results in:

An Exception Has Occurred

The root "viewvc.cgi" is unknown. If you believe the value is correct, then please double-check your configuration.
HTTP Response Status

404 Not Found
Comment 13 Jim Kyle 2009-03-31 12:09:13 UTC
Alan, is this related at all to Bug 4759?
Comment 14 James Richardson 2009-10-05 14:31:53 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.