More info from forums: http://forums.slimdevices.com/showthread.php?t=81128

From one user:

The following pattern is consistent:

Using Squeezebox Radio.
Using MySqueezebox.com
Snooze set for 10 minutes.
No other radios have any alarms set.
The behavior described is the same whether or not the battery is installed.

1. Alarm sounds at the right time using the right music
2. If snooze is not hit during the first minute, sound stops for a few seconds at the one minute mark, then starts up again.
3. At this point, if snooze is hit, it snoozes for the proper amount of time
4. It then sounds after the correct snooze time.
5. If you then hit snooze again either during the first minute or after the first minute, it snoozes for the right amount of time
6. It then sounds again - then you can either turn it off or snooze it again and it works fine.

OR..........

1. Alarm sounds at the right time using the right music
2. If snooze is hit during the first minute, music stops for a minute then turns back on.
3. Hit snooze again at this point and it snoozes for the right amount of time.
4. Behavior from this point on is proper.

Clearly something is happening at the one minute mark after the first alarm trigger. The behavior is different if you hit snooze during the first minute of the first firing of the alarm. If you let it play for a minute and let it fade and then let it come back the behavior from that point on is proper.

It's the one minute mark that should provide the clue to what the bug is.

First, I've selected "the current playlist" which happened to be a local radio station stream I was listening to at the time (News Talk Radio WABC 77 (AM)). Second, I've used a Sirius station and third, I've used one of my Pandora stations. I have not had a problem with the radio using the backup sounds under 9009.

Breaking up snooze into 2 issues:

Bug 16453: Press button sometimes results in snooze for incorrect interval
Bug 16446: Snooze switches to backup alarm when button not pressed

This will help focus the investigation.

Was able to reproduce:

1. Set alarm at 2:06 pm
2. Alarm rang at 2:06 pm (KQED-FM 88.5)
3. Pressed big knob sometime during 2:06 pm displayed on screen
4. Snooze ends sometime during 2:07 pm.
5. Pressing snooze again did not work. Had blue wireless icon, so probably could not communicate with MySB.com.
6. Snooze resumed when wireless icon turned white.

Log enclosed

Created attachment 6938 [details]
Log for alarm at 2:06 pm

1. Alarm rings at 2:06 pm, 2. Snooze pressed sometime during 2:06 pm 3. Snooze off sometime during 2:07 pm.

Also, second snooze period ended 10 minutes later -- as set on MySqueezebox.com

Created attachment 6939 [details]
Updated 2:06 pm log with end of 2nd snooze at 2:17 pm

Related?
https://bugs-archive.lyrion.org/show_bug.cgi?id=16465

Evaluated this bug extensively, and have come to the conclusion that this is a pref setting issue on the mysb.com side.

Bug can only be reproduced on mysb.com when no record exists for player_prefs.alarmSnoozeSeconds. In that situation, alarm snoozes only until the top of the next minute, then 10 minutes after next snooze, then 1 minute after next snooze.

I suggest that the behavior is that the client is sending the 'jivealarm' cli command to the server, the server is attempting $alarm->snooze(), and because it has no default it's failing to snooze correctly.

(In reply to comment #8)
> Evaluated this bug extensively, and have come to the conclusion that this is a
> pref setting issue on the mysb.com side.
> Bug can only be reproduced on mysb.com when no record exists for
> player_prefs.alarmSnoozeSeconds. In that situation, alarm snoozes only until
> the top of the next minute, then 10 minutes after next snooze, then 1 minute
> after next snooze.
> I suggest that the behavior is that the client is sending the 'jivealarm' cli
> command to the server, the server is attempting $alarm->snooze(), and because
> it has no default it's failing to snooze correctly.

There are reports on the forum that indicate that the behavior is the same when "off" is selected rather than "snooze". In other words. When "off" is selected during the first minute after an alarm sounds, the alarm comes back on within a minute.

Is this related? Or is this a separate bug?

Default88, could you open a new bug for that issue (and cc me on it to remind me :)

This specific bug turns out to be a dupe of bug 16465

*** This bug has been marked as a duplicate of bug 16465 ***

(In reply to comment #10)
> Default88, could you open a new bug for that issue (and cc me on it to remind
> me :)
> This specific bug turns out to be a dupe of bug 16465
> *** This bug has been marked as a duplicate of bug 16465 ***

Comments:
I'll open a new bug for the particular issue referred to.

Quite honestly, I don't understand how this bug is a duplicate of but 16465.  16465 seemed to be a feature request (snooze time is not available on the radio - and it isn't - it must be set within MYB or SBS).

What does that have to do with the behavior of the snooze when it is pressed during the first minute of the alarm sounding. In the example I provided and the behavior I described, I had set an appropriate snooze time on on MSB.com.

I think this bug was erroneously flagged as a duplicate.

However, I do think this bug is fixed, as least as far as my tests have shown.

The fix was entirely on the mysqueezebox.com code side, so no new firmware should be necessary to see the change in behavior.

Please advise if the 1 min/9 min/1 min snooze bug still shows up. For me it's now gone...

Sorry but this bug has not been fixed. The 1 minute snooze problem happened this morning with my alarm even though I had shut the alarm off.

(In reply to comment #13)
> Sorry but this bug has not been fixed. The 1 minute snooze problem happened
> this morning with my alarm even though I had shut the alarm off.

This problem is not fixed!!!  It occured again this morning just like before.

I am having the exact same issue with the Squeezebox Radio. I am running the 7.5.2 firmware. The radio is connected to mysqueezebox.com as is my Duet. I have no alarms on the Duet.

By the way, why isn't the snooze length configuration setting in the Squeezebox Server software or the device interface?

Can I ask that anyone that's reported the bug as not fixed in the past few days look on the bottom of their Radio and let me know what their MAC address is? This will allow me to view information about your player preferences there.

The root of this problem was determined to be an error in the default player preference stored in the mysqueezebox.com database for alarm snooze time. I'd tested the fix for this as working on a mysb.com-connected Radio, so my guess is that for those users still experiencing the problem their player pref is different than mine. That's what I think needs investigating next.

I've reproduced this with 7.5.1 r9009

alarm stream starts coming in at :58 seconds (:02 before the alarm time)
Sep  2 17:16:58 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder mp3
Sep  2 17:16:58 squeezeplay: INFO   audio.decode - Playback.lua:440 connect 207.200.96.140:80 GET /stream/1048 HTTP/1.0^M
Sep  2 17:16:58 squeezeplay: INFO   audio.decode - Playback.lua:443 GET /stream/1048 HTTP/1.0^M
Sep  2 17:16:58 squeezeplay: Accept: */*^M
Sep  2 17:16:58 squeezeplay: Cache-Control: no-cache^M
Sep  2 17:16:58 squeezeplay: User-Agent: iTunes/4.7.1 (Unix; N; linux; x86_64-linux; EN; iso-8859-1) SqueezeNetwork/7.5.2-sn/TRUNK^M
Sep  2 17:16:58 squeezeplay: Icy-MetaData: 1^M
Sep  2 17:16:58 squeezeplay: Connection: close^M
Sep  2 17:16:58 squeezeplay: Host: scfire-ntc-aa07.stream.aol.com^M
Sep  2 17:16:58 squeezeplay: ^M
Sep  2 17:16:59 squeezeplay: WARN   applet.ScreenSavers - ScreenSaversApplet.lua:264 "none" is the configured screensaver for whenStopped, so do nothing
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:307 notify_playerModeChange: player (LocalPlayer {Squeezebox Radio}) mode has been changed to play
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:312 notify_playerModeChange: - audioState is 1
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:134 notify_playerAlarmState received for LocalPlayer {Squeezebox Radio} with alarmState of active
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:139 **************************** notify_playerAlarmState received: active 0
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:712 _stopTimer: stopping RTC fallback alarm timer
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:487 openAlarmWindow()server true
Sep  2 17:17:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:527 openAlarmWindow: called with `server` - audioState is 1

at :09 second mark, snooze is hit. Log message shows the snooze time should be 300 seconds (matches the player pref for my player and for another user on this bug seeing the issue)

Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:813 _alarmSnooze: alarmInProgress is server : connection status is true
Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:818 _alarmSnooze: fallback alarm snoozing for 300  + 20 seconds
Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:769 starting RTC fallback alarm timer for interval 320000
Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:804 SEND WOL NOW
Sep  2 17:17:09 squeezeplay: WARN   squeezebox.server - SlimServer.lua:624 wakeOnLan(): SKIPPING WOL, self.mac: nil, self:isSqueezeNetwork(): true
Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:834 _alarmSnooze: sending snooze command to connected server for connected player LocalPlayer {Squeezebox Radio}
Sep  2 17:17:09 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:725 stopping decodeStatePoller
Sep  2 17:17:11 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:441 _menuSink(1) nil menuDirective: add isCurrentServer:true
Sep  2 17:17:11 squeezeplay: INFO   applet.SlimMenus - SlimMenusApplet.lua:713 hiding any 'connecting to server' popup after menu response from current server, SlimServer {mysqueezebox.com}
Sep  2 17:17:11 squeezeplay: INFO   applet.AlarmSnooze - AlarmSnoozeApplet.lua:261 notify_playerLoaded(LocalPlayer {Squeezebox Radio})
Sep  2 17:17:11 squeezeplay: INFO   applet.ChooseMusicSource - ChooseMusicSourceApplet.lua:543 Hiding popup, exists?: nil
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:307 notify_playerModeChange: player (LocalPlayer {Squeezebox Radio}) mode has been changed to stop
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:312 notify_playerModeChange: - audioState is 1
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:134 notify_playerAlarmState received for LocalPlayer {Squeezebox Radio} with alarmState of snooze
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:139 **************************** notify_playerAlarmState received: snooze 0
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:170 snooze state received
Sep  2 17:17:11 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:172 self.alarmInProgress set to: snooze
Sep  2 17:17:40 squeezeplay: WARN   applet.ScreenSavers - ScreenSaversApplet.lua:264 "none" is the configured screensaver for whenStopped, so do nothing

BUG reproduced: alarm stream restarts itself at :58, exactly 1 minute after alarm fired inititally
(I see no indication this is initiated from the client-side)

Sep  2 17:17:58 squeezeplay: INFO   audio.decode - decode_start_handler:275 init decoder mp3
Sep  2 17:17:58 squeezeplay: INFO   audio.decode - Playback.lua:440 connect 207.200.96.140:80 GET /stream/1048 HTTP/1.0^M
Sep  2 17:17:58 squeezeplay: INFO   audio.decode - Playback.lua:443 GET /stream/1048 HTTP/1.0^M
Sep  2 17:17:58 squeezeplay: Accept: */*^M
Sep  2 17:17:58 squeezeplay: Cache-Control: no-cache^M
Sep  2 17:17:58 squeezeplay: User-Agent: iTunes/4.7.1 (Unix; N; linux; x86_64-linux; EN; iso-8859-1) SqueezeNetwork/7.5.2-sn/TRUNK^M
Sep  2 17:17:58 squeezeplay: Icy-MetaData: 1^M
Sep  2 17:17:58 squeezeplay: Connection: close^M
Sep  2 17:17:58 squeezeplay: Host: scfire-ntc-aa07.stream.aol.com^M
Sep  2 17:17:58 squeezeplay: ^M
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:307 notify_playerModeChange: player (LocalPlayer {Squeezebox Radio}) mode has been changed to play
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:312 notify_playerModeChange: - audioState is 1
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:134 notify_playerAlarmState received for LocalPlayer {Squeezebox Radio} with alarmState of active
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:139 **************************** notify_playerAlarmState received: active 0
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:712 _stopTimer: stopping RTC fallback alarm timer
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:487 openAlarmWindow()server true
Sep  2 17:18:00 squeezeplay: WARN   applet.AlarmSnooze - AlarmSnoozeApplet.lua:527 openAlarmWindow: called with `server` - audioState is 1

if I snooze from here, the alarm will go off in ~4 minutes, matching up with when the snooze should have come back after the first alarm time was hit.

The behavior I'm seeing here is as if there are two alarms being fired, the second one 1 minute after the first one. I think there is a possibility that snooze interval is a red herring and this is actually an erroneous second alarm going off.

I should also note that in testing against a 7.6 Radio firmware I do not see this issue. However, the AlarmSnoozeApplet.lua files in 7.5/trunk and 7.6/trunk are currently identical. Very puzzling, that.

This morning I did a test with two radios, one running 7.6 r9037 the other running 7.5 r9009. Other than firmware revision, both were identically configured:

1. connected to mysb.com
2. player pref set to 5 minute snooze
3. same alarm tone (natural sounds->rural)
4. alarms set for exactly the same time

Both alarms fired within a second or two of each other. I hit snooze on both alarms. At the top of the following minute, the 7.5 firmware radio refired the alarm. The 7.6 firmware radio did not. I hit snooze again on the 7.5 firmware radio.

At 5 minutes after the initial alarm, both radios refired their alarms at the same time.

I see this as confirmation that a second alarm is being sent from the server to the 7.5 firmware radio, rather than an incorrect snooze time.

Will look further into code diffs between the two firmwares, but the AlarmSnoozeApplet code is identical between the two builds. Still feels like a server-side issue.

(In reply to comment #16)
> Can I ask that anyone that's reported the bug as not fixed in the past few days
> look on the bottom of their Radio and let me know what their MAC address is?
> This will allow me to view information about your player preferences there.
> The root of this problem was determined to be an error in the default player
> preference stored in the mysqueezebox.com database for alarm snooze time. I'd
> tested the fix for this as working on a mysb.com-connected Radio, so my guess
> is that for those users still experiencing the problem their player pref is
> different than mine. That's what I think needs investigating next.

I have tried the snooze function a couple of times.
I'm using 7.5.1 and the snooze seems to be working fine for me now.

*** Bug 16523 has been marked as a duplicate of this bug. ***

I am not sure what happened between Friday (9/10/2010) and Sunday (9/12/2010) but now when the alarm sounds no menu appears and when I press the knob on my Squeezebox Radio no the alarm continues to sound (i.e. it fails to snooze).  So when this happened I pressed the Power button and the alarm shut off.  A minute later the alarm sounded again.  Again the snooze failed as above so I pressed the power button again and the alarm shut off.  The alarm did not sound again until the prescribed time the next day (9/13/2010) when the same behavior occurred.

I've reproduced this bug in 7.6 firmware as well as 7.5 firmware, so I have to think my comment #19 was incorrect in stating that this is a 7.5 only issue.

It is, however, restricted to players connected to mysb.com. Problem is not manifested when connected to local SBS.

In all cases, the second alarm fires at the :00 second mark of the following minute, rather than 1 minute later. That still points to a second alarm firing, not an erroneous snooze interval.

Is this bug related to bug 16644?  Forum here http://forums.slimdevices.com/showthread.php?t=83230 indicated it was so I voted for both just in case.

Pinging Andy for update ....

This bug appears fixed in 7.5 trunk/Test SN.  It will be rolled out to production soon.

FYI, I've confirmed what Andy said in the previous comment. I can reproduce this issue easily on production mysb.com, but not against test.mysb.com (that has 7.5/trunk fixes in it)

This test was against SBRadio, 7.5.1 r9218