First Last Prev Next    This bug is not in your last search results.
Bug 15239 - Alarm starts with loud volume, then drops to the alarm starting volume
: Alarm starts with loud volume, then drops to the alarm starting volume
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Audio
: 7.4.x
: PC Windows Server 2003
: P1 normal (vote)
: 7.5.0
Assigned To: Alan Young
: radioAlarmsCritical
Depends on:
Blocks:
  Show dependency tree / graph
 
Reported: 2009-12-02 22:50 UTC by cradle22
Modified: 2010-04-27 17:52 UTC (History)
11 users (show)

See Also:
Category: Bug

Attachments
possible patch (540 bytes, patch)
2010-02-10 08:52 UTC, Alan Young 		Details | Diff
Patch to remove volumeLocal() call when processing playerstatus message (454 bytes, patch)
2010-02-22 14:26 UTC, Ben Klaas 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description cradle22 2009-12-02 22:50:00 UTC 
I use the Radio connected to SC NB 7.4.2. SC is on a Server which is always on.

The radio is configured not to use mySB.com

I use a natural sound (roling waves) as alarm sound, and a low starting volume for the alarm.

Apart from sometimes not working at all (which has been logged several times before), I have the following problem:

When the alarm starts, there is

a) An Audible "POP" from the speakers (I think it is the amplifier turning on)
b) The sound starts at a high volume (I would say about 50%-75% of maximum volume)
c) after about 1/2 second, the volume drops to the very low starting level which should have been used in the fist place, the gradually getting louder.


I want to be wakened "softly", so playing the alarm sound at a high volume even for a short period of time is not a desired behavior...


Thanks for your efforts...
Comment 1 Ben Klaas 2009-12-21 14:29:01 UTC 
flagging critical bugs for SB Radio with keyword radioAlarmsCritical
Comment 2 Ben Klaas 2009-12-21 14:35:27 UTC 
There is likely going to be a 7.4.2 release preceding 7.5.0, and it will be for fixes to the alarm.

Changing target and priority to reflect that.

FYI-- I can reproduce this infrequently and agree that it's an ugly one. I do not yet have a handle on why it's behaving as it does.
Comment 3 Ben Klaas 2009-12-22 13:16:01 UTC 
adding Felix to the cc: list. Felix, do you think you could help me with tracking down the root cause of this issue? I'm able to reproduce it, not 100% of the time, but reasonably frequently. The problem is that I'm not sure how to approach identifying the cause and engineering a fix.

My only working hunch is that it has something to do with the squeezeplay local playback control that Tom worked on last year to make things like play/pause more responsive on the squeezeplay side (i.e., not having to follow the typical request/response model of the client-server).
Comment 4 Ben Klaas 2010-01-05 13:07:21 UTC 
*** Bug 15411 has been marked as a duplicate of this bug. ***
Comment 5 Ben Klaas 2010-01-11 18:02:07 UTC 
checkin r8312 represents a significant overhaul to the alarm handling on the SB Radio side. Once we get the firmware out to beta users with these changes, I'd like to re-evaluate this bug to determine whether the problem still occurs, and if so if there's a particular reproducible case so we can hone in on a solution a.s.a.p. (likely the same one described in the initial bug report)
Comment 6 Ben Klaas 2010-01-19 14:36:04 UTC 
cradle22 at gmail, would you mind testing this again with a fully up-to-date SBS 7.4.2 and fully up-to-date SB Radio firmware?

QA, I'm assigning this to you for reproduction. There have been a lot of changes to make the alarm more robust in the last month, and there is some possibility this works reliably with those changes.

I tried and failed to reproduce using an alarm configured for Natural Sounds->Waves as its alarm sound. Audio faded in as desired in every test...
Comment 7 cradle22 2010-01-19 23:06:57 UTC 
(In reply to comment #6)
> cradle22 at gmail, would you mind testing this again with a fully up-to-date
> SBS 7.4.2 and fully up-to-date SB Radio firmware?
> 
> QA, I'm assigning this to you for reproduction. There have been a lot of
> changes to make the alarm more robust in the last month, and there is some
> possibility this works reliably with those changes.
> 
> I tried and failed to reproduce using an alarm configured for Natural
> Sounds->Waves as its alarm sound. Audio faded in as desired in every test...

Hello Ben,

I will try it out using the current server build (firmware should automatically update? I always update whenever the radio asks me to...).

And I will have to monitor this for some time, since the bug does not occur every time the alarm starts.

I will report back here, but it could take until the end of the week / weekend.

Kind regards,

Arndt
Comment 8 cradle22 2010-01-25 23:50:59 UTC 
(In reply to comment #6)
> cradle22 at gmail, would you mind testing this again with a fully up-to-date
> SBS 7.4.2 and fully up-to-date SB Radio firmware?
> 
> QA, I'm assigning this to you for reproduction. There have been a lot of
> changes to make the alarm more robust in the last month, and there is some
> possibility this works reliably with those changes.
> 
> I tried and failed to reproduce using an alarm configured for Natural
> Sounds->Waves as its alarm sound. Audio faded in as desired in every test...

Hello!


I have updated my Server to 7.4.2 from 21.01.2010. After some time the firmware of the radio was updated, as well.

Since then the alarm worked as it should for five times. But then it worked before, as well, only to produce the noise again for an unknown reason.

I will try to test some more scenarios, like killing the connection to the www (I do not use mySB, but one never knows...), restarting the server prior to the alarm etc.

I will report back after I have done this.

Kind regards,

Arndt
Comment 9 Bradley D. Wall 2010-01-28 15:30:55 UTC 
Using SB Server 7.4.1 on Windows Vista 32 bit, unable to reproduce error using SB Radio and Nature sounds, Lapping waves.  Was logged into mySB.com

Snoozed Radio
Comment 10 Richard van den Berg 2010-01-29 00:21:42 UTC 
Yesterday morning, while running 7.4.2 and the latest SB Radio firmware, I was already awake when the alarm went off. It started at normal volume right away, and did not fade in from 0. I checked the settings and they were at "fade in alarms" or whatever it's called.

I'm not sure if is related, but I thought I'd mention it.
Comment 11 Stefan Hansel 2010-01-30 02:02:37 UTC 
If anyone missed it, Marc could reproduce this bug and also provides logs which give a hint of why this might happen:

http://forums.slimdevices.com/showthread.php?t=74438

Note that this was after 80% of changes Ben did for the alarm reliability - so I guess the issue isn't fixed yet (though difficult to reproduce reliably).

@Chris: shouldn't this one be flagged for target milestone 7.4.2 ?
Comment 12 cradle22 2010-01-31 22:31:28 UTC 
Hello!

Sadly I can also report that it does not work well. Somehow today it even was worse than before (but this could be random).

I describe what happened:

Yesterday I turned the radio on and listened to a internet radio station by pressing the third favorites button. After some time I turned the radio off.


This morning I the alaram fired, not using the "rolling waves" I have configured at all, but the internet radio station (and at a very high volume, without even dropping to the fade-in).

I don't use the snooze function, I simply turn the alarm off by using the "On / Off" button of the radio. The device turned of all right (saying something like "alarm turned off".

But: Only to turn the alarm on again about three seconds later, using the rolling waves (and doing the correct fade in). I had to run the alarm off again.

I am 100% sure that I turned the alarm off the first time, and I only have one alarm configured for each work day.

So it seems to be broken still. Sadly I have not been able to consistently reproduce this. I will try fiddling with the favorites, but I am sure that it happened before without priorily listening to a favorite.

Kind regards,

Arndt
Comment 13 Kris Murphy 2010-02-02 11:14:28 UTC 
I have reproduced this twice using SC 7.4.2 on Windows 7 using My Playlist.  Then I switched to Lapping Waves and the alarm worked fine.  I reset the alarm again using Lapping Waves and the issue was once again reproduced.
Comment 14 Chris Owens 2010-02-02 14:11:55 UTC 
Ben I don't know where in our architecture this might be, but I'll start off with you since I know you have alarms in your head.  Feel free to assign it on or bring it up at the bug meeting.
Comment 15 Ben Klaas 2010-02-02 15:07:27 UTC 
Yes, this is correctly assigned.

My working theory is that the local volume control implementation (put in to decrease lag on volume changes, which used to do be dependent on the server) is causing the problem. In a nutshell, the initial audio comes in with an out of sequence packet and the client-side ignores it.

Tom knows way more about this than I do. Hopefully getting a brain dump from him on this and a few other subjects tomorrow night.
Comment 16 Stefan Hansel 2010-02-03 07:31:14 UTC 
Ben, I'm able to reproduce this now for 75% of my test-alarms.
If you need any logs from the server or radio with certain debug-levels let me know. 

This is my setup:

Local SB-Server, created a new playlist containing just mp3-songs, set this playlist for the alarm.
I never get this problem, when the alarm is set to an internet stream by the way.
Comment 17 Ben Klaas 2010-02-09 08:49:48 UTC 
An analysis of the server side of this is showing that the volume is not initially set low when the alarm first fires. This feels like a smoking gun, but note that this debug is not from when the issue was reproduced (that is, radio doesn't blast at high volume to begin alarm)

However, this seems very indicative of the problem at hand-- the alarm fires initially at the wrong volume level, and only catches up with the fade-in after a few times calling Slim::Player::Client::volume

[10-02-09 10:44:00.0035] Slim::Player::Client::volume (827) vol: 53
[10-02-09 10:44:00.0141] Slim::Utils::Misc::msg (1165) Warning: [10:44:00.0138] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Alarm.pm line 623)
   frame 2: Slim::Utils::Alarm::sound (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 3: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 4: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 5: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 6: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 7: main::idle (./slimserver.pl line 580)
   frame 8: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:00.0152] Slim::Player::Client::volume (827) vol: 53
[10-02-09 10:44:00.0163] Slim::Utils::Misc::msg (1165) Warning: [10:44:00.0158] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Player.pm line 83)
   frame 2: Slim::Player::Player::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Prefs/Base.pm line 307)
   frame 3: Slim::Utils::Prefs::Base::set (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 844)
   frame 4: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 5: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Alarm.pm line 623)
   frame 6: Slim::Utils::Alarm::sound (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 7: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 8: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 9: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 10: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 11: main::idle (./slimserver.pl line 580)
   frame 12: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:00.8039] Slim::Player::Client::volume (827) vol: 53
[10-02-09 10:44:00.8050] Slim::Utils::Misc::msg (1165) Warning: [10:44:00.8047] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1211)
   frame 2: Slim::Player::StreamingController::_Stream (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 288)
   frame 3: Slim::Player::StreamingController::_eventAction (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 732)
   frame 4: Slim::Player::StreamingController::_nextTrackReady (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 692)
   frame 5: Slim::Player::StreamingController::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Song.pm line 336)
   frame 6: Slim::Player::Song::getNextSong (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 697)
   frame 7: Slim::Player::StreamingController::_getNextTrack (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 921)
   frame 8: Slim::Player::StreamingController::_StopGetNext (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 288)
   frame 9: Slim::Player::StreamingController::_eventAction (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1966)
   frame 10: Slim::Player::StreamingController::play (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 976)
   frame 11: Slim::Control::Commands::playlistJumpCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 12: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 13: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 14: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 15: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 1639)
   frame 16: Slim::Control::Commands::playlistXtracksCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 17: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 18: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 19: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 20: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 1304)
   frame 21: Slim::Control::Commands::playlistXitemCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 22: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 23: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 24: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 25: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Alarm.pm line 629)
   frame 26: Slim::Utils::Alarm::sound (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 27: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 28: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 29: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 30: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 31: main::idle (./slimserver.pl line 580)
   frame 32: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:00.8082] Slim::Player::Client::volume (827) vol: 53
[10-02-09 10:44:00.8094] Slim::Utils::Misc::msg (1165) Warning: [10:44:00.8092] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox.pm line 203)
   frame 2: Slim::Player::Squeezebox::play (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 376)
   frame 3: Slim::Player::Squeezebox2::play (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1225)
   frame 4: Slim::Player::StreamingController::_Stream (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 288)
   frame 5: Slim::Player::StreamingController::_eventAction (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 732)
   frame 6: Slim::Player::StreamingController::_nextTrackReady (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 692)
   frame 7: Slim::Player::StreamingController::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Song.pm line 336)
   frame 8: Slim::Player::Song::getNextSong (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 697)
   frame 9: Slim::Player::StreamingController::_getNextTrack (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 921)
   frame 10: Slim::Player::StreamingController::_StopGetNext (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 288)
   frame 11: Slim::Player::StreamingController::_eventAction (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1966)
   frame 12: Slim::Player::StreamingController::play (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 976)
   frame 13: Slim::Control::Commands::playlistJumpCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 14: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 15: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 16: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 17: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 1639)
   frame 18: Slim::Control::Commands::playlistXtracksCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 19: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 20: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 21: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 22: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Commands.pm line 1304)
   frame 23: Slim::Control::Commands::playlistXitemCommand (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 24: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 1940)
   frame 25: Slim::Control::Request::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Control/Request.pm line 879)
   frame 26: Slim::Control::Request::executeRequest (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Client.pm line 651)
   frame 27: Slim::Player::Client::execute (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Alarm.pm line 629)
   frame 28: Slim::Utils::Alarm::sound (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 29: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 30: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 31: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 32: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 33: main::idle (./slimserver.pl line 580)
   frame 34: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:03.5466] Slim::Player::Client::volume (827) vol: 0.000130152702331543
[10-02-09 10:44:03.5475] Slim::Utils::Misc::msg (1165) Warning: [10:44:03.5473] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Player.pm line 429)
   frame 2: Slim::Player::Player::_fadeVolumeUpdate (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Player.pm line 370)
   frame 3: Slim::Player::Player::fade_volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/SqueezePlay.pm line 206)
   frame 4: Slim::Player::SqueezePlay::fade_volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1312)
   frame 5: Slim::Player::StreamingController::_Start (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1377)
   frame 6: Slim::Player::StreamingController::_StartIfReady (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 1392)
   frame 7: Slim::Player::StreamingController::_WaitToSync (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 288)
   frame 8: Slim::Player::StreamingController::_eventAction (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/StreamingController.pm line 2134)
   frame 9: Slim::Player::StreamingController::playerBufferReady (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 145)
   frame 10: Slim::Player::Squeezebox2::statHandler (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/Slimproto.pm line 871)
   frame 11: Slim::Networking::Slimproto::_stat_handler (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/Slimproto.pm line 408)
   frame 12: Slim::Networking::Slimproto::client_readable (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 139)
   frame 13: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 123)
   frame 14: Slim::Networking::IO::Select::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 15: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 16: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 17: main::idle (./slimserver.pl line 580)
   frame 18: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:03.5967] Slim::Player::Client::volume (827) vol: 0.132971835136414
[10-02-09 10:44:03.5978] Slim::Utils::Misc::msg (1165) Warning: [10:44:03.5975] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Player.pm line 429)
   frame 2: Slim::Player::Player::_fadeVolumeUpdate (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 3: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 4: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 5: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 6: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 7: main::idle (./slimserver.pl line 580)
   frame 8: main::main (./slimserver.pl line 1072)

[10-02-09 10:44:03.6487] Slim::Player::Client::volume (827) vol: 0.27089136838913
[10-02-09 10:44:03.6496] Slim::Utils::Misc::msg (1165) Warning: [10:44:03.6493] Backtrace:

   frame 0: Slim::Player::Client::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Squeezebox2.pm line 265)
   frame 1: Slim::Player::Squeezebox2::volume (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Player/Player.pm line 429)
   frame 2: Slim::Player::Player::_fadeVolumeUpdate (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 3: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Utils/Timers.pm line 255)
   frame 4: Slim::Utils::Timers::__ANON__ (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 5: (eval) (/home/bklaas/squeezecenter/7.5/trunk/server/Slim/Networking/IO/Select.pm line 183)
   frame 6: Slim::Networking::IO::Select::loop (./slimserver.pl line 626)
   frame 7: main::idle (./slimserver.pl line 580)
   frame 8: main::main (./slimserver.pl line 1072)
Comment 18 SVN Bot 2010-02-09 14:40:46 UTC 
 == Auto-comment from SVN commit #30117 to the  repo by bklaas ==
 == https://svn.slimdevices.com/?view=revision&revision=30117 ==

Bug: 15239
Description: don't set the client volume from Slim::Utils::Alarm if _fadeInSeconds() returns true
Comment 19 Ben Klaas 2010-02-09 15:33:09 UTC 
Stefan- would you mind giving this a try with SBS 7.5 >= svn r30117?

My hunch is that this is not completely fixed yet, but I'm focusing on the server side of this now because there is clear indication the volume is initially set incorrectly (more than once, actually). 

But I can't actually reproduce the volume glitch any more, and since you say you can regularly reproduce this, I thought I'd solicit your feedback.
Comment 20 Ben Klaas 2010-02-10 07:01:50 UTC 
Executive summary debug

When alarm fires, there are still two spots in the code where $client->volume is being forcefully set before the volume kicks in. In both cases, there is no value for $tempVolume, which means it is not obeying anything dealing with fade. The fade in volume behavior starts about a second and a half after these two events

Log:
[10-02-10 08:50:00.0262] Slim::Player::Client::volume (827) vol: 50, temp: 
[10-02-10 08:50:00.0290] Slim::Player::Client::volume (827) vol: 50, temp: 
[10-02-10 08:50:01.7731] Slim::Player::Client::volume (827) vol: 0.000132322311401367, temp: 1
[10-02-10 08:50:01.8247] Slim::Player::Client::volume (827) vol: 0.129184722900391, temp: 1
[10-02-10 08:50:01.8767] Slim::Player::Client::volume (827) vol: 0.259077548980713, temp: 1
[10-02-10 08:50:01.9287] Slim::Player::Client::volume (827) vol: 0.389099717140198, temp: 1

I've done backtraces on both of these settings and these are the two places in the code that are hit:

line 1211 of Slim::Player::StreamingController:

1205         foreach my $player (@{$self->{'players'}}) {
1206                 if ($setVolume) {
1207                         # Bug 10310: Make sure volume is synced if necessary
1208                         my $vol = ($prefs->client($player)->get('syncVolume'))
1209                                 ? $masterVol
1210                                 : abs($prefs->client($player)->get("volume") || 0);
1211                         $player->volume($vol);
1212                 }


line 203 of Slim::Player::Squeezebox:

 201 
 202         # make sure volume is set, without changing temp setting
 203         $client->volume($client->volume(), defined($client->tempVolume()));
 204 

These are both called when Slim::Utils::Alarm does a request execute for commands e.g. [ 'playlist' 'play' ]

What I'd like to do is not set the volume in either place when a fadeIn is being done, but it appears that information is lost in the stack somewhere...
Comment 21 SVN Bot 2010-02-10 08:28:20 UTC 
 == Auto-comment from SVN commit #30129 to the  repo by bklaas ==
 == https://svn.slimdevices.com/?view=revision&revision=30129 ==

Bug: 15239
Description: revert r30117
Alan advises that this was not a fix at all, but will result in the alarm not being able to fade in to the final alarm level setting
Comment 22 Ben Klaas 2010-02-10 08:30:21 UTC 
I've exhausted my ability to fix this bug.

Unassigning the bug and adding the bug_meeting keyword.
Comment 23 Alan Young 2010-02-10 08:52:55 UTC 
Created attachment 6504 [details]
possible patch

This may resolve the problem is there is some kind or race condition occurring in the player but I have been unable to find one.
Comment 24 Chris Owens 2010-02-18 09:31:18 UTC 
Alan, Ben says he has exhausted his brain on this bug.  Since you had some thoughts on it, could you have a look?
Comment 25 Alan Young 2010-02-19 05:57:02 UTC 
Has anyone come up with a reproducible test case?
Comment 26 Stefan Hansel 2010-02-19 08:04:53 UTC 
(In reply to comment #25)
> Has anyone come up with a reproducible test case?

As written in comment #16 not quite reproducable but >50%, when I create a new playlist, put an mp3 into it and make this playlist an alarm sound.
Not reproducable when using an internet-radio-stream as alarm sound..

Radio is wireless with latest 7.4.2 firmware push, SB-server (running on a SheevaPlug) is 7.4.2 Beta but I didn't update the last two weeks. 
MySB.com not involved for me.
Comment 27 Alan Young 2010-02-22 05:47:34 UTC 
This looks like it is the cause:

Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - Playback.lua:815 gainL, gainR: 13 13
Feb 22 14:25:59 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:711 send opcode=STAT
Feb 22 14:25:59 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:513 read opcode=strm #28
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - Playback.lua:564 strm u
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - Playback.lua:644 resume unpause
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - decode_resume_audio:594 decode_resume_audio start_jiffies=0
Feb 22 14:25:59 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:711 send opcode=STAT
Feb 22 14:25:59 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Squeezebox Touch 1}) mode has been changed to play
Feb 22 14:25:59 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 0
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:133 decode_resume_audio_handler start_interval=0
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - debug_fullness:107 fullness: 53534 / 1078648 | 1.70% / 30.57%
Feb 22 14:25:59 squeezeplay: DEBUG  audio.output - decode_alsa_resume:67 decode_alsa_resume
Feb 22 14:25:59 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:149 resume_audio decode state: 1 audio state 40
Feb 22 14:26:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:115 notify_playerAlarmState received for LocalPlayer {Squeezebox Touch 1} with alarmState of active
Feb 22 14:26:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:117 **************************** notify_playerAlarmState received: active 0
Feb 22 14:26:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:382 openAlarmWindow()server true
Feb 22 14:26:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:422 openAlarmWindow: called with `server` - audioState is 1
*** Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:769 setVolume: 70
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:787 _setGain: 12032
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:815 gainL, gainR: 12032 12032
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:331 status TRACK STARTED (elapsed: 796)
Feb 22 14:26:00 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:711 send opcode=STAT
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:491 disconnect streambuf
Feb 22 14:26:00 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:711 send opcode=DSCO
Feb 22 14:26:00 squeezeplay: DEBUG  net.slimproto - SlimProto.lua:513 read opcode=audg #26
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:884 stopping local pause timer
Feb 22 14:26:00 squeezeplay: DEBUG  audio.decode - Playback.lua:815 gainL, gainR: 13 13

Playback.lua:setVolume() is being called with value 'high' (70 in this case => gain := 12032), when the gain had been set just before to 13.

This is probably the responsible code: Player.lua:_process_status()

	--might use server volume
	if useSequenceNumber then
		if isSequenceNumberInSync then
			local serverVolume = self.state["mixer volume"]
			if serverVolume ~= self:getVolume() then
				--update local volume so that it is persisted locally (actual volume will have already been changed by audg sub)
				if serverVolume == 0 and self:getVolume() and self:getVolume() < 0 then
					--When muted, server sends a 0 vol, ignore it
					self.state["mixer volume"] = oldState["mixer volume"] 
				else
					self:volumeLocal(serverVolume)
				end
			end
		else
			log:debug("volume value ignored(out of sync), revert to old: ", oldState["mixer volume"])
			self.state["mixer volume"] = oldState["mixer volume"]
		end

		--finally if we were out of sync at the receipt of playerstatus, refresh so server is in sync with all value
		if not isSequenceNumberInSync then
			self:refreshLocallyMaintainedParameters()
		end
	end

It is assuming that the volume reported by the server is the volume that the player is supposed to be playing at, but this is not true when the server is managing a fade. The comment notes that the volume has already been set by an 'audg' packet so it seems inappropriate for this code to be setting it again. I guess it needs an alternative way to persist the volume locally (whatever that means) without actually changing the player volume.
Comment 28 Alan Young 2010-02-22 06:27:53 UTC 
It would be possible to do the full long-fade-in in f/w - it would work for both ip3k (SB2+) and SP players. The disadvantage would be that the user would not be able to override the volume during this period as the f/w does not cancel a fade-in because of user volume changes.
Comment 29 Ben Klaas 2010-02-22 06:39:01 UTC 
Wouldn't it be simpler to flag those "high volume" packets as ones that are to be ignored by SP?

It bothers me that the server is sending them in the first place, but if they have to go out, it strikes me they should be flagged in some way so the client can selectively ignore them.
Comment 30 Ben Klaas 2010-02-22 14:24:07 UTC 
I removed the volumeLocal() call in Player.lua when processing player status and I see evidence that it no longer incorrectly sets the gain.

I'm very wary of this change though...there's even a comment in Player.lua saying exactly why the volumeLocal() call is in there. I don't fully understand the implications of this change, or where it would adversely affect the player's behavior.


log at alarm time after patch applied: 

Feb 22 16:00:57 squeezeplay: INFO   audio.decode - Playback.lua:407 100.0%/99.8%
Feb 22 16:00:58 squeezeplay: INFO   audio.decode - Playback.lua:407 100.0%/99.8%
Feb 22 16:00:59 squeezeplay: INFO   audio.decode - Playback.lua:407 100.0%/99.8%
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:564 strm q
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_stop:659 decode_stop
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_stop_handler:197 decode_stop_handler
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:149 source=off
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:491 disconnect streambuf
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 4608 4608
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 4608 4608
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:564 strm q
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_stop:659 decode_stop
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_stop_handler:197 decode_stop_handler
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:484 flush streambuf
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 4608 4608
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:564 strm s
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:484 flush streambuf
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_start:697 decode_start
Feb 22 16:00:59 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder mp3
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_output_set_track_gain:577 Track gain 65536
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_output_set_track_gain:581 Track clip range 7fffffff 80000000
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - decode_set_track_polarity_inversion:586 Polarity inversion 0
Feb 22 16:00:59 squeezeplay: INFO   audio.decode - Playback.lua:436 connect 192.168.1.2:9000 GET /stream.mp3?player=00:04:20:26:03:42 HTTP/1.0^M
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:149 source=stream
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - stream_connectL:454 streambuf connect 192.168.1.2:9000
Feb 22 16:00:59 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:00:59 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 4608 4608
Feb 22 16:00:59 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:420 _menuSink(1) nil menuDirective: add isCurrentServer:true
Feb 22 16:00:59 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:692 hiding any 'connecting to server' popup after menu response from current server, SlimServer {mediumspicy}
Feb 22 16:00:59 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:239 notify_playerLoaded(LocalPlayer {Radio})
Feb 22 16:00:59 squeezeplay: INFO   applet.ChooseMusicSource - ChooseMusicSourceApplet.lua:540 Hiding popup, exists?: nil
Feb 22 16:01:00 squeezeplay: DEBUG  audio.decode - Playback.lua:356 resume decoder, 2896 bytes buffered, decode threshold 2048
Feb 22 16:01:00 squeezeplay: DEBUG  audio.decode - decode_resume_decoder:572 decode_resume_decoder
Feb 22 16:01:00 squeezeplay: DEBUG  audio.decode - decode_resume_decoder_handler:117 resume_decoder decode state: 1 audio state 0
Feb 22 16:01:00 squeezeplay: DEBUG  audio.decode - debug_fullness:107 fullness: 2896 / 0 | 0.09% / 0.00%
Feb 22 16:01:00 squeezeplay: DEBUG  audio.decode - decode_output_samples:385 first buffer sample_rate=44100
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:260 notify_playerModeChange: player (LocalPlayer {Radio}) mode has been changed to play
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:262 notify_playerModeChange: - audioState is 0
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:115 notify_playerAlarmState received for LocalPlayer {Radio} with alarmState of active
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:117 **************************** notify_playerAlarmState received: active 0
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:574 _stopTimer: stopping RTC fallback alarm timer
Feb 22 16:01:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:382 openAlarmWindow()server true
Feb 22 16:01:01 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:422 openAlarmWindow: called with `server` - audioState is 0
Feb 22 16:01:01 squeezeplay: WARN   squeezebox.player - Player.lua:1295 Do nothing, as the playerstatus message should not be setting the volume
Feb 22 16:01:01 squeezeplay: INFO   audio.decode - Playback.lua:407 0.0%/20.3%
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:390 status FULL
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 13 13
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:564 strm u
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:644 resume unpause
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - decode_resume_audio:593 decode_resume_audio start_jiffies=97821292
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:133 decode_resume_audio_handler start_interval=-109
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - debug_fullness:107 fullness: 173085 / 1184632 | 5.50% / 33.58%
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - decode_resume_audio_handler:149 resume_audio decode state: 1 audio state 40
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 13 13
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:331 status TRACK STARTED
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 14 14
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 14 14
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 14 14
Feb 22 16:01:02 squeezeplay: DEBUG  audio.decode - Playback.lua:885 stopping local pause timer
Feb 22 16:01:02 squeezeplay: WARN   audio.decode - Playback.lua:816 gainL, gainR: 15 15
Comment 31 Ben Klaas 2010-02-22 14:26:14 UTC 
Created attachment 6554 [details]
Patch to remove volumeLocal() call when processing playerstatus message
Comment 32 Ben Klaas 2010-02-22 14:27:36 UTC 
Alan, back to you for review. As I stated in the last comment, I'm very wary of this change as I believe it removes something that was already explicitly defined as to its intentions. 

I don't understand the full implications of this change, but I did confirm that the volume gain is not incorrectly set in this particular test case.
Comment 33 SVN Bot 2010-02-23 02:08:23 UTC 
 == Auto-comment from SVN commit #8550 to the  repo by ayoung ==
 == https://svn.slimdevices.com/?view=revision&revision=8550 ==

Fixed bug 15239: Alarm starts with loud volume, then drops to the alarm starting volume 
Only update volume state variable for the LocalPlayer->Playback upon receiving a playerStatus
update and leave all server-initiated actual volume changes to Slimproto 'audg' packets.
Comment 34 Alan Young 2010-02-23 02:10:36 UTC 
Update hours and product
Comment 35 davenva 2010-03-14 18:26:21 UTC 
I am still experiencing this problem - 100% of the time.
Comment 36 Alan Young 2010-03-14 23:24:25 UTC 
(In reply to comment #35)
> I am still experiencing this problem - 100% of the time.

What firmware do you have?
Comment 37 davenva 2010-03-18 16:40:59 UTC 
(In reply to comment #36)
> (In reply to comment #35)
> > I am still experiencing this problem - 100% of the time.
> 
> What firmware do you have?

I just upgraded to 7.4.2 R8423.

I had the problem before the update, and I still have it after.

I use one of the standard sounds, nothing fancy.

Alarm starts with a loud volume blast of the sound for about 1 second, then does the expected fade-in.  By that time, it's too late ;)
Comment 38 Alan Young 2010-03-19 00:07:06 UTC 
The fix will be delivered in 7.5.0
Comment 39 Chris Owens 2010-04-08 17:26:25 UTC 
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!
Comment 40 davenva 2010-04-27 17:52:31 UTC 
Confirmed - bug is fixed in 7.5

Thanks
First Last Prev Next    This bug is not in your last search results.