Bug 10064 - SqueezeCenter doesn't always auto-generate playerstatus when it needs to
: SqueezeCenter doesn't always auto-generate playerstatus when it needs to
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: SB Server
: unspecified
: PC Other
: P3 normal (vote)
: 7.5.0
Assigned To: Alan Young
:
Depends on:
Blocks: 8300
  Show dependency treegraph
 
Reported: 2008-11-18 18:01 UTC by Ben Klaas
Modified: 2010-04-08 17:25 UTC (History)
8 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Klaas 2008-11-18 18:01:24 UTC
screensaver continues to show now playing and elapsed time goes ad infinitum

this has to be related to the playerstatus subscription change.

mine to investigate and fix for 7.3
Comment 1 Ben Klaas 2008-11-19 12:40:09 UTC
Problem is that SqueezeCenter should be sending playerstatus notifications in at least one spot, if not more.

When the playlist finishes and player changes mode to "stopped" nothing is communicated from SC to the playerstatus subscription.
Comment 2 sbjaerum 2008-11-20 11:18:58 UTC
When my controller enters the now playing screensaver, the progress bar and the numbers on each side stops updating. Exiting the screensaver to the now playing screen (with icon bar at the bottom), the progress bar and numbers starts to update again. When entering the screensaver again, they stop.
I am using firmware r3411.
Comment 3 Ben Klaas 2008-11-20 13:07:31 UTC
Comment #2 of this bug is a separate, needs-to-be-fixed, bug. I will open it.
Comment 4 Ben Klaas 2008-11-21 12:10:30 UTC
rewriting summary to reflect nature of bug
Comment 5 James Richardson 2008-12-19 08:02:30 UTC
Changing target to next release
Comment 6 Adrian Smith 2009-01-21 15:17:52 UTC
I suspect the commented out code at line 404 in StreamingController may have something to do with it... 

There are no notifications sent when a stream stops at present.
Comment 7 Ben Klaas 2009-01-22 07:35:28 UTC
Triode pointed out that the commented line from Slim::Player::StreamingController, shown below, in order to close bug 7781 is probably the root of the problem with this bug.

cc:ing Andy

sub _notifyStopped {
        my $self   = $_[0];
        my $master = master($self);

        foreach my $player ( @{ $self->{'players'} } ) {
                # XXX: Bug 7781, Some plugins (Alarm) don't like extra stop events
                # I'm sure commenting this out will break something else -andy
                # Slim::Control::Request::notifyFromArray( $player, ['stop'] );
        }
}
Comment 8 Chris Owens 2009-03-16 09:40:42 UTC
We are now planning to make a 7.3.3 release.  Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future.

Thanks!
Comment 9 Chris Owens 2009-03-30 17:19:28 UTC
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out.  If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it.

Thanks.
Comment 10 Ben Klaas 2009-05-19 07:10:47 UTC
*** Bug 12096 has been marked as a duplicate of this bug. ***
Comment 11 Blackketter Dean 2009-07-22 08:39:46 UTC
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code.  Feel free to move it back if it's specific to the single original product.
Comment 12 Ben Klaas 2009-08-23 20:21:37 UTC
I just reviewed my comment#7 and looked at the code in Slim::Player::StreamingController and that line has now been uncommented:

  foreach my $player ( @{ $self->{'players'} } ) {
                # This was previously commented out, for bug 7781, 
                # because some plugins (Alarm) don't like extra stop events.
                # This broke important notifications for Jive.
                # Other changes mean that that this can be reinstated.
                Slim::Control::Request::notifyFromArray( $player, ['playlist', 'stop'] ) unless $suppressNotifications;

                if ($player->can('onStop')) {
                        $player->onStop();
                }
        }


I think this means that playerstatus may be able to be moved off of 30 second subscription back to a full "push" type subscription. I will test this tomorrow and if it checks out this bug can probably close. If it doesn't work as hoped, I will defer to 8.0.
Comment 13 Ben Klaas 2009-08-23 21:46:20 UTC
This bug has been deemed not important for 7.4 release
Comment 14 SVN Bot 2009-12-23 12:05:16 UTC
 == Auto-comment from SVN commit #8262 to the jive repo by bklaas ==
 == https://svn.slimdevices.com/jive?view=revision&revision=8262 ==

Fixed Bug: 8300
Fixed Bug: 10064
Description: move playerstatus subscription to a "full push" model rather than push + 30 second poll

the danger here is if playerstatus isn't auto-generated when it should be (bug 10064) and instead of refreshing withing 30 seconds, it's stale until the next notification auto-generate, which could be much longer.

It's time to quit evading this bug though-- if 10064 still is out there, let's flush out those bugs and get them fixed rather than take this defensive stand that makes the network chatter much higher than it should be.
Comment 15 Alan Young 2010-01-19 03:50:53 UTC
The various playlist commands are still missing for synced players, as is 'playlist newsong' for radio streams.
Comment 16 SVN Bot 2010-01-19 04:56:23 UTC
 == Auto-comment from SVN commit #29842 to the slim repo by ayoung ==
 == https://svn.slimdevices.com/slim?view=revision&revision=29842 ==

Fixed bug 10064 (again, better): SqueezeCenter doesn't always auto-generate playerstatus when it needs to.
Player-status needs to be triggered whenever the playlist or playing state changes. It turns out that, in all cases, there are either explicit 'playlist' notifications or the change is caused by a 'playlist' command. Treat notifications for 'playlist xxxx'  as special and distribute them to all the interested listeners and subscriptions for all the active (ON) players in the initiating player's sync-group. Consequently, it is no longer necessary to loop over all the active players in a sync-group when generating explicit 'playlist' notifications.
Comment 17 Chris Owens 2010-04-08 17:25:30 UTC
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!