Bugzilla – Bug 16480
Volume get set at 100% when player is selected by Controller or Touch
Last modified: 2010-08-24 14:37:23 UTC
Bugzilla was down so i made this tread: http://forums.slimdevices.com/showthread.php?t=81393 I paste the messages chronologically here here: Latest 7.6 everything... 9056 and latest server Version: 7.6.0 - r31224 @ Fri Aug 20 03:02:01 MDT 2010 How to reproduce: let for example your Boom play some local flac files . grab your controller, select another player start that one for a while then stop it. Now choose the boom, when it switches over quickly choose the now playing screen now the boom volume should go to 100% from what ever it was. Or if paused unpause and it starts at 100% volume . Or for really wet pants, choose the other player don't do anything with the controller, wait for the now playing screen to come alive on the controller, *then* the volume raises to 100% ouch. 100% reproducable with BOOM,SB3 and Touch controlled by a Controller
I don't sync the players But if i did , I do not even have the sync volume function enabled. This is still happening . Considering there is some people that managed to breake the speaker in their boom's with normal listening this bug is potentially product destroying ? I know you don't work weekends , but bug's off these magnitude usually peaks interest anyway . Now on 9057 on controller and Touch I've found another easier way to simulate, just switch players and then touch the volume control on the controller . Doing it with the Touch yields the same result aargh, I selected more logging the "Server" set and the bug dissapeared. For a while when i used the controller, then I deselected the logg set and the bugg is still gone from the controller ! But it still happens when I control the BOOM with the Touch ?? But after 20 minutes while fiddling with the Touch the controller was back to have the bug for a while and then it was gone again . There must be something very slippery going on as the controller does not always have this anymore since fiddling with the servers logging . Timing of somekind Messages in the Touch says this, very interesting: Aug 22 12:23:10 squeezeplay: INFO squeezeplay.applets - AppletManager.lua:708 store settings: SlimDiscovery Aug 22 12:23:12 squeezeplay: INFO applet.NowPlaying - NowPlayingApplet.lua:390 notify_playerDigitalVolumeControl Aug 22 12:23:12 squeezeplay: INFO applet.SlimBrowser - SlimBrowserApplet.lua:3672 notify_playerDigitalVolumeControl()1 Aug 22 12:23:12 squeezeplay: WARN applet.SlimBrowser - SlimBrowserApplet.lua:3682 reset volume to cached level: 100 Aug 22 12:23:17 squeezeplay: INFO applet.NowPlaying - NowPlayingApplet.lua:390 notify_playerDigitalVolumeControl Aug 22 12:23:31 dropbear[10947]: Child connection from 192.168.1.4:48819 Aug 22 12:23:41 dropbear[10947]: password auth succeeded for 'root' from 192.168.1.4:48819 OK Hmm SlimbrowserApplet
The same happens when switching between my SB3 and BOOM with the controller Volume get set to 100% on BOOM or SB3 . Also the same happens whether I have 100% fixed volume on Touch or not. Tried with Touch volume at 80% all players still gets 100% when switched to, including the Touch, so they don't inherits each others volume ? Btw the controller is back to have the bug 100% of the time Here is when the Touch gets it volume raised by the NP screen: Aug 22 13:01:01 squeezeplay: INFO applet.NowPlaying - NowPlayingApplet.lua:390 notify_playerDigitalVolumeControl Aug 22 13:01:01 squeezeplay: INFO applet.NowPlaying - NowPlayingApplet.lua:400 enable volume UI in NP Aug 22 13:01:01 squeezeplay: INFO applet.SlimBrowser - SlimBrowserApplet.lua:3672 notify_playerDigitalVolumeControl()1 Aug 22 13:01:01 squeezeplay: WARN applet.SlimBrowser - SlimBrowserApplet.lua:3682 reset volume to cached level: 100 Aug 22 13:01:20 squeezeplay: INFO squeezeplay.applets - AppletManager.lua:708 store settings: Playback You select player then wait and when the NP screen kicks in the volume goes to 100% Btw http://forums.slimdevices.com/showpost.php?p=571191&postcount=7 Ben said he have a look
I marked it as critical, because it's potential to blow speakers . Se treads about people blowing their boom speakers, the protection in boom don't seem to work as designed.
I started the "prefs" logging and watched the output: At exactly the moment when i chosed "now playing" on my controller i got this [10-08-24 14:55:41.1301] Slim::Utils::Prefs::Base::set (238) setting server:00:04:20:1e:e6:5d:volume to 100 The sequence was from another player (my SB3) chose BOOM go to now playing . 00:04:20:1e:e6:5d is my boom. I also tried some slimproto lgging but it did not make sense to me. And it's real heisenbug more player logging makes the bugg almost go away 1 try in 20 gave the buggy behaviur?
With controll command logging I see : [10-08-24 15:26:51.4081] Slim::Control::Request::dump (2431) Request: Command [00:04:20:1e:e6:5d->mixer volume] from /c24957a9/slim/request|328| (Dispatchable) [10-08-24 15:26:51.4092] Slim::Control::Request::dump (2435) Param: [_newvalue] = [100] [10-08-24 15:26:51.4119] Slim::Control::Request::notifyFromArray (838) (prefset server volume 100) [10-08-24 15:26:51.4143] Slim::Control::Request::dump (2431) Request: Command [00:04:20:1e:e6:5d->mixer volume] from /c24957a9/slim/request|328| (Done) [10-08-24 15:26:51.4154] Slim::Control::Request::dump (2435) Param: [_newvalue] = [100] [10-08-24 15:26:51.4163] Slim::Control::Request::executeDone (1964) 0 [10-08-24 15:26:51.4208] Slim::Control::Request::notify (2074) Notifying mixer volume [10-08-24 15:26:51.4270] Slim::Control::Request::notify (2074) Notifying prefset [10-08-24 15:26:51.4286] Slim::Control::Request::notify (2112) Notifying Slim::Networking::SqueezeNetwork::PrefSync::prefEvent of prefset =~ [['prefset']] [10-08-24 15:26:51.4309] Slim::Control::Request::notify (2112) Notifying Plugins::SettingsManager::Plugin::prefEvent of prefset =~ [['prefset']] Well now I think I reached the limit for what I can do without input from you. Good luck finding the problem.
The problem is almost certainly a client-side bug introduced by my recent work on the fixed digital volume support. I will try to address this as soon as I can. It's my top priority 7.6 bug, but I have a 7.5 bug that I need to look at first. While volume being erroneously set at 100 is entirely unacceptable, be assured that a boom with volume at 100 will not destroy your product. We turned down the maximum gain to ensure that.
(In reply to comment #6) > The problem is almost certainly a client-side bug introduced by my recent work > on the fixed digital volume support. > Thats very plausible my radio is on 9037 and if I use that as a controller this problem do not happen. I'll wait and work around, 7.5 is more urgent
== Auto-comment from SVN commit #9067 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=9067 == Fixed Bug: 16480 Description: dump self.cachedVolume when attaching a new player to squeezeplay control
Mikael, I think that last checkin should do it. Reopen if you still see the bug after updating to >= 7.6 r9067.
whoops, this should still be set to RESOLVED
Will try 9067 as soon it get's built, thankyou