Bugzilla – Bug 8959
Boom Local Control when SqueezeCenter/Network Down
Last modified: 2013-05-17 18:44:26 UTC
We have no real control over Boom when either SqueezeCenter/Network are down, or there is a network lag of some form. Two examples where Boom becomes unresponsive: 1) If you shut off SqueezeCenter in a hard-way (close laptop, system reboots, squeezecenter crashes, etc), Boom will continue to play out the buffer. However you cannot power the unit off, raise or lower volume, or pause playback. 2) If you have a network lag of any kind (music has just started streaming and is flooding the network, server lag spike, etc), volume control is sometimes not responsive. This can be a huge pain if you need to raise or lower the volume quickly and you're waiting for the server to catch up. Volume control should be local, and then fed back to the server as an update.
I'm not sure of the right way to handle this. We just implemented clever scrolling acceleration in the server. It's not necessarily trivial to repeat that exact same algorithm in the client. How do we decide whether to use local volume control or remote? Is it purely local, then remote is updated. Or should it be remote only, until connection latency gets too high, the switch to local?
A couple of thoughts: 1. If the player is disconnected and playing audio, use local volume control (like we have for line in) when a volume button is pressed. 2. If the player is disconnected and the user hits the power or pause button, we should stop playing immediately. 3. If the player is disconnected and the user navigates out of the connecting screen, stop playing immediately. I don't think we want to stop playing automatically when disconnecting, I believe that there temporary disconnections that happen invisibly (i.e. when microwaving a burrito) that shouldn't cause the music to stop while the player is trying to reconnect.
Maybe someone can fill me in on the historical reason why we (from a player) it works the way ti does right now? This is the way I understand it: User Increases Volume By Remote -> SB3 sends VOLUMEUP to Server -> Server sends VOLUMEUP to SB3? User Increases Volume from SC -> Server sends VOLUMEUP to SB3 Why wouldnt this be reversed most of the time? User Increases Volume by Remote (or knob) -> SB3/Boom Increases Volume -> SB3/Boom sends "Volume Went Up" to Server To Update UI User Increases Volume from SC -> Server sends "You should increase your volume" to SB3/Boom -> SB3/Boom VOlume Increases I understand that the "visual" volume control is still sent by the Server, but who cares if that's "delayed" a bit ... no one is actually setting their volume based on the visuals anyways... its all done by ear, right?
I really don't know how to do this easily. Sean or felix, can you take a look at this one? I don't know how to know if we're disconnected, nor how to invoke the local volume control.
I've added code in fw for all players (SB3, TR, SBR and Boom) to address item 2 and 3 from Dean's list in comment #2. (Item 1 from that list is trickier to do right and I guess it needs some more discussion first on how it should be addressed correctly.) If disconnected and music is still playing, it can be stopped by pressing POWER, PAUSE, LEFT, REW or any volume button. On Boom it can be stopped in addition by pressing HOME. On Ray it can be stopped by pressing the one and only available button. Will be in SB3 fw 108, TR fw 57, SBR fw 43 and Boom fw 24
Felix: What do you need for #1?
Well, I guess at a minimum we would need a way to report back the current (offline) volume when reconnecting, else it could happen that a user turns down the volume while offline and upon reconnecting the volume would jump up to the previous volume level still stored in SC/SN.
If we just implement full (always) local volume control where the only updates sent to the server are "this is my current volume, deal with it", it solves almost all of our problems. I know its not simple to implement, but seems like the "right" solution. Especially with Boom, by the way, the Server should NEVER over-write whatever the Boom thinks its current volume is upon connection. I could imagine someone not knowing the volume was 'last set at 100 on SC' and connecting the boom to SC only to be quite surprised when the volume is maxed out.
Doh, there will be no 7.4 - moving it to 8.0
Apparently, simple network latency can cause me to lose control of the volume and other controls. It makes us look shockingly unprofessional when a Boom or other squeezebox "locks up" for whatever reason and I can't change the volume control (well, I can change it, but nothing happens for several seconds until the latency goes away, then all changes are applied at once). The net effect is that users essentially can't turn down their volume without unplugging the device when this happens (and it happens to me at home quite frequently, once or twice a week on average).
Targeting based on engineering discussion
I don't have anything useful to add other than, from a consumer standpoint, this is a fairly big glitch that can be quite troublesome. On several occasions I have experienced the latency where I cannot adjust the volume immediately, but since I tried to, the network eventually catches up and now I'm maxed at level 100 (very annoying - hopefully no possibility of damage to the speakers?). Of course I immediately try to lower the volume and several seconds later I'm now "muted" on level "0". Can anyone answer whether there is a danger to the speakers? If I remember correctly from doing my research on whether or not to select a Boom, I think there are internal controls that prevent that.