Bugzilla – Bug 10092
Squeezebox volume set to zero after an alarm
Last modified: 2009-07-31 10:32:17 UTC
After an alarm has gone off (playing either Internet radio or music library content) the volume on the Squeezebox is set to zero - rather than resetting to the player volume level before the alarm. It appears that the problem only exists if the alarm is manually stopped. If the alarm runs for the full 'time out' period (and turns off automatically), the previous (pre alarm) volume is restored correctly.
Some more info: Running SC 7.3 (23938) Mac Mini Core Duo Squeezebox v3; firmware 119 Wired connection The alarm is set to 'fade in' - despite that bug 10060 means that this function doesn't work.
Problem also exists with alarm 'fade in' disabled.
Richard: can you please attach a log file of the error
Created attachment 4319 [details] Log file with various server options set to 'debug'
Comment on attachment 4319 [details] Log file with various server options set to 'debug' A log for an alarm that fired at 09:28. Not sure if I have captured anything useful or not. If not - please let me know which logging settings you woudl like to see.
Max: can you take a look at this?
Andy and Michael both note they have seen this bug. Andy to have a look for 7.3 since Max isn't available for a while.
I do see this a lot but can't reproduce it now. QA: can you take a crack at it? Enable player.alarmclock debugging.
Created attachment 4332 [details] player.alarmclock degugging Thanks for the update. Tried again with player.alarmclock debugging set. Test process: 1. Set alarm (with radio source) using web interface 2. Wait for alarm to trigger 3. Wait 30-45 seconds listening to alarm 4. Cancel alarm using power button on remote 5. Turn on Squeezebox using remote. Browse to music library source. Play an MP3 6. Observe volume setting First try (alarm fired at 22:39) did not reproduce the problem. Pre-alarm volume was restored successfully. Second attempt (alarm fired at 22:42) did reproduce the problem. Volume was at zero when playing music library content. Log file is attached which shows both attempts. To the untrained eye, the logs look the same... Please let me know if you want me to try again with additional logging.
Created attachment 4333 [details] player.alarmclock = debug Worked for me 7.3 r24035
Richard: thank you for the log..Clearly it's a 2-stage issue I did my test with a single alarm, then re-tested using your setup of 2 alarms and guess what?? BAM the error happens. On my 2nd alarm off, the volume is set to 0 .. Just like your log shows.
Ah, thanks, I will retest.
OK I think this is probably due to a value in tempVolume being used as the current volume and reset when the alarm is done. I was still not able to reproduce it but after looking at your log I think this is the problem. Should be fixed in change 24059. Please test with tonight's nightly.
I'm still seeing the same issue, I'm afraid. Using build 24080. Let me know if you want to see any more logs.
Hmm, yes, another log would be good.
Actually - let me reconsider that. It's entirely possible that during testing, my 'previous' volume was set to zero following the alarm going off this morning with the original code. I will be sure to set the original volume to something other than zero and test again! :)
I've tested about a dozen times now and haven't been able to reproduce the problem. We're looking good! Many thanks all - and apologies for the false alarm earlier...
*** Bug 9886 has been marked as a duplicate of this bug. ***
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