Bugzilla – Bug 6584
allow configurable behavior for SBR button
Last modified: 2011-01-13 23:03:21 UTC
According to Dean, the button on the SBR acts as Pause/Unpause: http://forums.slimdevices.com/showpost.php?p=254747&postcount=53 I think users with multiple players who sync their SBR with other players might want different behavior: http://forums.slimdevices.com/showthread.php?t=42076 Since "pause" for a player that is synced to others results in the entire sync group pausing playback, I think many users would want the button on a synced SBR to act like a Power toggle -- allowing the rest of the sync group to keep playing when the SBR goes silent, and having the SBR rejoin the sync group when its button is pressed again. Best, I think, would be giving users options: 1) "smart" operation (pause if SBR acting alone, power if SBR synced with other players) 2) always treat like pause 3) always treat like power_toggle Option 1 would be great with SyncOptions (http://www.tux.org/~peterw/slim/SyncOptions.html) and local MP3 or FLAC tracks, as the effect of the On or Unpause press would be to start playing music -- either what the Receiver last played (if acting alone) or what the sync group is playing (if synced).
Peter: do you have a patch for this?
Sorry, Dean, no patch -- no way to test, as I don't have Receiver hardware, only the JHB controller.
Created attachment 2685 [details] first stab at "smart" behavior patch Here's an initial stab at "smart" button operation (giving users the three choices I suggested is easy; making SC7 implement the "smart" and "always treat as power" options is the tough part) that I've tested only very lightly, and without any speakers hooked up, to give you a rough idea what I've been looking at. I think it would probably be cleaner to assign a new IR code to the SBR button and map that to a new button name, but I assume that would require an SBR firmware update.
The main concern that led to this ticket was the how Power and Pause affect sync groups. Since SC7 has a Power On Resume option, perhaps the best thing to do is - have the SBR button act as Power -- either 1) change the firmware to send the frontpanel power code, or 2) hack Slim/Hardware/IR kinda like my previous patch, or 3) --this would be the most work, but would be most flexible for users & developers -- change the firmware to send a new frontpanel code and add SC7 code to interpret that code by default as Power - have the default Power On Resume setting for a new SBR be "Pause at power off / Resume at power on" Then you'd have out-of-the-box behavior like Dean described (the button acts like pause [at least for that SBR]) in both "solo" and sync group operation. I haven't tested this yet --for instance, this approach depends very much on whether "Pause at power off" really means execute a pause command before powering off (which would mess up sync groups), or if that only means that the SBR stops playing tracks when shut off-- I'm just thinking out loud again.
retargeting due to the short amount of time
This probably bears review by Alan.
Looks ok (the patch). It is a bit of a hack but is probably as good way of doing it as anything. I have tried to preserve the nuances of power/pause/sync behaviour in new-streaming, with some improvements. The option of simply changing the behaviour from Pause to Power would best be done in firmware, then no hack would be needed. The best option would be a new IR code so any future change would be easy and unambiguous. In the absence of a firmware change, we should probably just have the 'hack' remap the code to a new one (that would otherwise be done in firmware). I guess that 0001000a/0002000a would be fine. I cannot find anywhere in the documentation that says that pressing the button does Pause. So changing it to Power should be no big deal. Changing the power-on/power-off behaviour is still open to the user. That way we don't need any other changes. In the patch: (scalar(@{$client->slaves}) > 0) || ($client->masterOrSelf ne $client) could be replaced by: Slim::Player::Sync:isSynced($client) and, with new-streaming, this will become: $client->isSynced() But, like I said earlier, I would be in favour of just remapping it permanently. I'm not going to do this for 7.1 (I think), so I am marking this as 7.2. I'd appreciate any further comments on the above.
Dean, can you comment on this please.
Ping Dean
For what it's worth, I just released a new version of my KidsPlay plugin that allows users to have SqueezeCenter execute one or more CLI commands when someone presses the Receiver's button. For instance, by mapping the button to "button power_toggle", you can switch its behavior from Pause to Power -- and then you'd just need to check one more setting to get the solution I outlined in comment #4. http://www.tux.org/~peterw/slim/KidsPlay.html http://forums.slimdevices.com/showthread.php?t=66840 This doesn't help folks who connect directly to SqueezeNetwork, but for everybody else, maybe this is good enough. There are few enough votes for this bug, maybe this is good enough?
No more comments from anyone on the CC list, and there's a plugin workaround for folks running SqueezeCenter -- I'm closing as a WONTFIX (that's not a complaint, just trying to be accurate about the disposition -- if there's a SC/SBS workaround and not much interest in a SqueezeNetwork solution, it seems quite reasonable not to implement this enhancement request). Thanks.
I'm not really sure it's the role of someone who isn't a Logitech employee and isn't assigned to the bug to close it as WONTFIX.
He predicted the SW team's decision correctly in this case. :)
(In reply to comment #0) > Since "pause" for a player that is synced to others results in the entire sync > group pausing playback, I think many users would want the button on a synced > SBR to act like a Power toggle -- allowing the rest of the sync group to keep > playing when the SBR goes silent, and having the SBR rejoin the sync group when > its button is pressed again. i realize the bug is closed, but if you're doing a plugin or something my Q is this: why not just make it mute/unmute? being involved in sync'ing seems needlessly complex.
These are all bugs that have been marked 'fixed' or 'closed' but still have the bug_meeting keyword. They were not showing up in James's bug meeting search. Please let me know (chris_owens@logitech.com) if these need to be brought up at the next bug meeting. In the meantime I will fix the search.