Bugzilla – Bug 7990
CLI: Status subscribe: not all players notified when synchronization is cancelled
Last modified: 2009-07-31 10:20:15 UTC
Both my players are synced. I subscribe to status events on both players: <playerid> status - 0 subscribe:0 When I do: <playerid_1> sync - I am only getting one status event. Is this correct behaviour?
After a bit of discussion, we seem to have a consensus that this behavior is probably not a bug. Can you give us a bit more detail on what behavior you're expecting that this is a problem for you? Thanks!
Please check this "conversation" with the cli: # request the players: players 0 2 # response: players 0 2 count%3A2 playerindex%3A0 playerid%3A00%3A04%3A20%3A12%3A57%3Ad7 uuid%3A ip%3A192.168.1.110%3A38495 name%3ASB%20Ovenpaa model%3Asqueezebox2 isplayer%3A1 displaytype%3Agraphic-320x32 canpoweroff%3A1 connected%3A1 playerindex%3A1 playerid%3A00%3A04%3A20%3A06%3A93%3A72 uuid%3A ip%3A192.168.1.131%3A35232 name%3ASB%20Nedenunder model%3Asqueezebox2 isplayer%3A1 displaytype%3Agraphic-320x32 canpoweroff%3A1 connected%3A1 # get the status of both players and subscribe to status: # - request player 1: 00%3A04%3A20%3A12%3A57%3Ad7 status - 0 subscribe:0 # response player 1: 00%3A04%3A20%3A12%3A57%3Ad7 status - 0 subscribe%3A0 player_name%3ASB%20Ovenpaa player_connected%3A1 power%3A1 signalstrength%3A58 mode%3Astop remote%3A1 current_title%3ADR%20Oline time%3A0 rate%3A1 mixer%20volume%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1210008375.83844 playlist_tracks%3A2 # request player 2: 00%3A04%3A20%3A06%3A93%3A72 status - 0 subscribe:0 # response player 2: 00%3A04%3A20%3A06%3A93%3A72 status - 0 subscribe%3A0 player_name%3ASB%20Nedenunder player_connected%3A1 power%3A0 signalstrength%3A73 mode%3Astop remote%3A1 current_title%3ADR%20Oline time%3A0 rate%3A1 mixer%20volume%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1209914612.16678 playlist_tracks%3A2 # now sync the two players. request: 00%3A04%3A20%3A12%3A57%3Ad7 sync 00%3A04%3A20%3A06%3A93%3A72 # response: 00%3A04%3A20%3A12%3A57%3Ad7 sync 00%3A04%3A20%3A06%3A93%3A72 # this triggers status notifications for both players, as both players sync status has changed. response: 00%3A04%3A20%3A12%3A57%3Ad7 status - 0 subscribe%3A0 player_name%3ASB%20Ovenpaa player_connected%3A1 power%3A1 signalstrength%3A58 mode%3Astop remote%3A1 current_title%3ADR%20Oline time%3A0 rate%3A1 sync_master%3A00%3A04%3A20%3A12%3A57%3Ad7 sync_slaves%3A00%3A04%3A20%3A06%3A93%3A72 mixer%20volume%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1210008375.83844 playlist_tracks%3A2 00%3A04%3A20%3A06%3A93%3A72 status - 0 subscribe%3A0 player_name%3ASB%20Nedenunder player_connected%3A1 power%3A0 signalstrength%3A75 mode%3Astop remote%3A1 current_title%3ADR%20Oline time%3A0 rate%3A1 sync_master%3A00%3A04%3A20%3A12%3A57%3Ad7 sync_slaves%3A00%3A04%3A20%3A06%3A93%3A72 mixer%20volume%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1210008375.83844 playlist_tracks%3A2 # Now unsync the two players (I believe that it's only necessary to unsync one player as there is no sense in one synced player) # request: 00%3A04%3A20%3A06%3A93%3A72 sync - # response: 00%3A04%3A20%3A06%3A93%3A72 sync - # and status response for only one player. This is the bug! There should be status response for both players as both players sync status have changed! 00%3A04%3A20%3A06%3A93%3A72 status - 0 subscribe%3A0 player_name%3ASB%20Nedenunder player_connected%3A1 power%3A0 signalstrength%3A76 mode%3Astop remote%3A1 current_title%3ADR%20Oline time%3A0 rate%3A1 mixer%20volume%3A100 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1209914612.16678 playlist_tracks%3A2
Alan: Can you have a look at this, then add your comments
I guess that this is probably a bug although I'm not exactly sure what changes are considered to be status changes for the purpose of this subscription. It is certainly the case that becoming part of a sync group (both players for a two-player sync group) should constitute a status change as certain behaviour will change. It is less clear that this is also the case for remaining players in a sync-group when one player leaves. But, as I said, this is probably a bug.
Anders, since right now you are the only person seeing this, could you give us a feeling for how serious this is for you? Are you working on a plugin and it is stalling your effort? Thanks!
It's fine by me, I work around it by requesting the status for each players manually when I receive the response of the player that was unsynced. Just thought I'd report it as a bug.
Okay we will put it on the back burner for now and check in again from time to time. Anyone running across this, please leave comments and votes if it's important to you to fix this. There are plans for architectural changes which may fix this bug as we move forward, as well.
This happens because the code assumes (wrongly in the case of sync) that only changes to the player being subscribed to matter. Top of statusQuery_filter contains the line: return 0 if $clientid ne $self->clientid(); A simple fix would be to just add "return 1.3 if request->isCommand[sync]" (syntax approximate) -- any change in sync would trigger a notification to all players, sync'd or not. A smarter patch would see if the subscribed player is really impacted or not by checking the sync groups, etc. HTH
Fixed by new-streaming changes in 7.3
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC