Bugzilla – Bug 9833
RTC alarm should only be set if the next alarm is within 24 hours
Last modified: 2009-07-31 10:31:17 UTC
If SqueezeCenter goes down and an alarm is set for a future date and time the Boom activates the alarm at that time on the next day regardless of what date the alarm was set for. For example, if you have an alarm defined for Mon-Fri at 07:00 to get you up for work and SC goes down on Saturday night then the fallback alarm will sound at 07:00 on Sunday morning. This has been reported in the forums by myself: http://forums.slimdevices.com/showthread.php?t=53488 and another person: http://forums.slimdevices.com/showthread.php?p=353956
I had the same thing occur over the weekend. a 4:42 alarm on Monday was triggered at 4:42 on Sunday, becuase the SC/SN connection failed before 4:42 on Sunday. The Boom must evaluate only the time of the next alarm, and not date, when decided when to trigger it's single emergency alarm.
Verified, the backup alarm will be triggered at the appropriate time, but not date. Max if you need a log, re-assign it to me and I'll generate one.
Sorry, I have no time to work on SC issues at the moment. Please check before assigning things to me as I'm pressed even to read bugmail right now. The Boom's backup RTC does not store a date component. There's therefore a call between it going at the time of the next alarm (but not necessarily the right day) or it not going off at all if SC is down for more than 24 hours.
(In reply to comment #3) > The Boom's backup RTC does not store a date component. There's therefore a > call between it going at the time of the next alarm (but not necessarily the > right day) or it not going off at all if SC is down for more than 24 hours. Can the firmware of the Boom not be updated so that the RTC /does/ store a date component?
No, it's a hardware limitation.
(In reply to comment #5) > No, it's a hardware limitation. In that case a setting in SqueezeCenter where, under these circumstances, you could choose to switch of the backup alarm or have it in enabled would be good. There are situations where I /deliberately/ what my server to be switched off.
Changed summary from "Fallback Alarm Does Not Honour Selected Days"
Should this be communicated more clearly? The alarm is something people really rely on, and while I know it'll be rare that SC/SN is down for more than 24 hours in a row, and the user has missed that the alarm has triggerd, but on the wrong day...I just feel like it should be stated up front for people using this as their only alarm. For example, I can't decide to not fix my broken SC instance on a Sunday in the knowledge that I'll at least get Monday's alarm.
I've just had a quick look at the code. The expected behaviour is that the RTC alarm is only set if the next alarm is within 24 hours. Otherwise, it sets a timer to check again in 24 hours. You therefore won't get an RTC alarm if the connection to a server is lost more than 24 hours before the next alarm is due, but it should work otherwise. You should not get an RTC alarm for an alarm that is due in more than 24 hours. There's obviously a bug somewhere. Once the RTC alarm is set, it remains set until the server connection is restored. Basically, you should get woken up once and then restore the server connection. If not, you'll get the same alarm again in 24 hours. That's by design. Any changes to this would be at firmware level.
(In reply to comment #9) > I've just had a quick look at the code. The expected behaviour is that the RTC > alarm is only set if the next alarm is within 24 hours. Otherwise, it sets a > timer to check again in 24 hours. You therefore won't get an RTC alarm if the > connection to a server is lost more than 24 hours before the next alarm is due, > but it should work otherwise. You should not get an RTC alarm for an alarm > that is due in more than 24 hours. That's good news - the intended behaviour seems to acceptable, at least to me. Since the intended behaviour isn't occurring then I'd suggest that the aim of this bug report should be to restore this intended behaviour. But perhaps some would still like the ability to disable the fall back alarm - but this maybe better as separate enhancement requuest.
Okay I changed the summary to reflect the actual bug. If people still feel a need for the ability to disable the RTC, please open a new bug (enhancement).
Max: I'm moving this bug to future for now, if you have time to address this bug before that time, please target. If anyone else feels strongly on this bug, please comment and provide a patch.
Could someone provide a simple test case to reproduce this bug, please?
To reproduce you should be able to: 1) Set an alarm for a time, two days ahead of you. So for example, today (Friday) set an alarm for Sunday at 09:00. 2) Shut down SqueezeCenter today at some point. 3) With SC still shutdown, the RTC alarm will now sound on Saturday at 09:00, not Sunday. Unfortunately I think you'll always have to set the alarm at least 24 hours ahead of being able to confirm the bug. Thats my understanding of it.
Could QA confirm this bug using the above test case, please?
(In reply to comment #15) > Could QA confirm this bug using the above test case, please? > Working on it, player.alarmclock debug, any other logs?
player.alarmclock is all I'd need. I'm in campfire at the moment, by the way.
I see the following in the log - when I set the clock 48 + hours in advance. Shutting down the server I see the alarm icon on the player UI [09-01-13 11:14:43.7139] Slim::Utils::Alarm::_startStopTimeCheck (1747) 1 scheduled alarm(s) [09-01-13 11:14:43.7141] Slim::Utils::Alarm::findNextTime (437) Potential next time found: 9:0:0 15/1/2009 [09-01-13 11:14:43.7144] Slim::Utils::Alarm::scheduleNext (1313) Next alarm is at 9:0:0 15/1/2009 [09-01-13 11:14:43.7146] Slim::Utils::Alarm::scheduleNext (1325) Scheduling alarm [09-01-13 11:14:43.7149] Slim::Utils::Alarm::_startStopTimeCheck (1747) 2 scheduled alarm(s) [09-01-13 11:14:43.7151] Slim::Utils::Alarm::setRTCAlarm (1357) Asked to set rtc alarm for BOOM:01:cc [09-01-13 11:14:43.7154] Slim::Utils::Alarm::setRTCAlarm (1388) Setting RTC alarm to 32400, volume 50
Hmm, that looks wrong. I'll take a look tomorrow if I can.
Just had a quick look at the code and spotted what looks like a really silly mistake - I've subtracted two values the wrong way round. I can't see how I wouldn't have spotted this before, so will take another look tomorrow when I'm more awake and do the fix then if it is what I think. The fix would be very low risk. Where would you want it - the 7.3 trunk?
Taking. (Why does 'Accept bug (change status to ASSIGNED)' never work??)
Created attachment 4643 [details] Fix for bug This trivial patch should fix this problem. I can't test this at the moment, so it's worth testing afterwards that the rtc alarm does sound if it is within 24 hours and that it doesn't if it isn't.
Would you like the attached patch to be included in 7.3.2?
Great news, I'll check out the patch. Please check it into 7.3.3 (when available)
Max: Looks good, check into 7.3.2 please
Committed to 7.3.2 as change 24690.
Verified fixed in SqueezeCenter 7.3.2 r24695
observed this morning, v7.3.4 this time the alarm went off as intended BUT: After sleep mode 45 minutes of random play (fyi) 7AM wake up alarm, radio stream started ok 8AM (after the Alarm) by itself, it continues with the random play hello? sometimes the alarm icon just disappears, I assume in this case the following day I would be late for work. right now, the alarm icon is overwritten by the time and date (half of the Icon at least) it is hard not to mention that I find roughly 10000 bugs in a stereo is a bit too much
(In reply to comment #28) > observed this morning, v7.3.4 Please cut&paste the version information, as the above is invalid. Please test with the release version of 7.3.2, after installing this version, remove all your alarms, then setup the alarms again. > > this time the alarm went off as intended This is a good thing, NO? > > > BUT: > > After sleep mode 45 minutes of random play (fyi) > 7AM wake up alarm, radio stream started ok > 8AM (after the Alarm) by itself, it continues with the random play This is confusing. please explain in a bit more detail. > > sometimes the alarm icon just disappears, I assume in this case the following > day I would be late for work. > > right now, the alarm icon is overwritten by the time and date (half of the Icon > at least) > What is your display setting? does this happen when the unit is off, standby, now playing? a bit more detail please. Do you have a 3rd party plug-in that is changing the display?
Wouldn't it be better to discuss this in the forums? It doesn't sound related to this bug.
Max: you are quite right, thank you. stef: I am closing this bug, as the original issue is fixed and verified. IF you still have issues, please discuss it in the forums, email me directly, or open a new bug.
Fixed - Closed Message (SC) This bug has been fixed in the 7.3.3 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.
Correction: SqueezeCenter version is 7.3.2
Reduce number of active targets for SC