Bugzilla – Bug 10064
SqueezeCenter doesn't always auto-generate playerstatus when it needs to
Last modified: 2010-04-08 17:25:30 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
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.
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 #2 of this bug is a separate, needs-to-be-fixed, bug. I will open it.
rewriting summary to reflect nature of bug
Changing target to next release
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.
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'] ); } }
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!
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.
*** Bug 12096 has been marked as a duplicate of this bug. ***
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.
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.
This bug has been deemed not important for 7.4 release
== 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.
The various playlist commands are still missing for synced players, as is 'playlist newsong' for radio streams.
== 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.
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!