Alarm not reliable... is this issue already known?

[kartman_canada]

Hello...

I've had Squeeze products for years and love them. I've been eying a BOOM for a while and finally pushed the button and bought it. Other than the obvious use as another player in my home, it's primary purpose is as an alarm clock.

Bottom line - I'm very disappointed with the lack of reliability.

I realize others have been having issues too and many seem to be new issues since moving to 7.4.X of the server. I've contacted Logitech to log an problem and I got the "we know about it and are working on it" answer but I want to make sure the developers are aware of MY issue. Obviously, there are many reasons that the alarm might fail and none of the posts I've found seem to describing my findings (see log). Unfortunately, we all might not get up on time though..

I'm running 7.4.1 at the moment and the server is up 100% of the time. I set my alarm for 5 days a week (repeating) at 7am to wake to a favorite that is a streamed radio station. For no reason that I can figure, some days the alarm just doesn't go... silence... not acceptable. The logs (attached) say "alarm late by xxx seconds... skipping" What?!?!

I've set the server to "debug" logging on the alarm function and attached the log. The attachment has 2 days of alarms where the first day was successful and the 2nd failed.

Sorry for the long post. I just want identify whether my issue is known and to find a path to getting the alarms working reliably. I've yet to try moving to one of the 7.5.x builds.

Thanx.

[jrichardson]

Search the Bug Report system, you will find a few reports on Alarms.

Post your findings in those reports, and add your self to the CC list so you will now when they are fixed.

https://bugs.slimdevices.com/

[kartman_canada]

Search the Bug Report system, you will find a few reports on Alarms.

Post your findings in those reports, and add your self to the CC list so you will now when they are fixed.

https://bugs.slimdevices.com/

Happy to help... I found bug 14870 but I'm not clear about whether this is the same issue or whether I should raise a new bug. I want to contribute but I also want to make sure I'm doing it in the correct fashion and in the correct forum.

Please advise, if you can.

[MikeekiM]

Early on, my alarm failed me... But has not failed me in months... I am thinking that I may have screwed up in setting the alarm, and probably as due to user error...

The last 6+ months, my alarm has been flawless...and even when my server goes down, the default alarm wakes me...

[jrichardson]

Does removing all the alarms, from both the device and web ui's. then adding them back using JUST the device ui help?

[andyg]

[09-11-25 07:01:50.5827] Slim::Utils::Alarm::sound (521) Alarm is 110 seconds early/late - ignoring

So there's the reason it didn't go off, for some reason the alarm timer is going off almost 2 minutes later than it should be. Probably we should fix this so alarms that trigger late for whatever reason still go off. But why would it be going off late I wonder? Is your server really online 100% of the time or do you put it to sleep?

[kartman_canada]

[09-11-25 07:01:50.5827] Slim::Utils::Alarm::sound (521) Alarm is 110 seconds early/late - ignoring

So there's the reason it didn't go off, for some reason the alarm timer is going off almost 2 minutes later than it should be. Probably we should fix this so alarms that trigger late for whatever reason still go off. But why would it be going off late I wonder? Is your server really online 100% of the time or do you put it to sleep?

I agree totally about the triggering late alarms but I can't tell you why it would be late in the first place. I've not submitted a bug about this as I was trying to determine if this issue had been identified already before I tossed more fuel on the fire.

To answer your question, the server is online "100%" of the time. I'm not putting it to sleep in any fashion as far as I know. I only phrased my comment like that as nothing is truly 100% up. I'm not quite sure about the process of triggering an alarm. Does the server trigger or does the Boom trigger? The log mentions setting the RTC and I had assumed this was within the Boom as a potential backup.

I've been checking my server's desktop clock against the rest of the network and it is in sync. My server is running on Fedora 8 within a VMware virtual machine. Could this be a potential reason for the alarm being early/late?

Any suggestions about what I should log at DEBUG level in order to capture something else useful? Since my original post, I've upgraded to the nightly build of 7.5.x to see if the issue has gone away. Of course, I've found other issues to boot but my alarm didn't go off this AM. I've not had a chance to dig into the log to see if they look the same as with 7.4.1.

Getting a bit frustrated and I can't express how disappointed I am overall. This is very different than my experience with all my Squeeze devices prior to purchasing the Boom.

THanx.

[kartman_canada]

Does removing all the alarms, from both the device and web ui's. then adding them back using JUST the device ui help?

Tried this... In fact, this was my first angle of attack. Sadly, no... the alarms still continue to fail is a somewhat random fashion but always with the "early/late... skipping" message in the log.

[DotSystem]

Hello...
Sorry for the long post. I just want identify whether my issue is known and to find a path to getting the alarms working reliably. I've yet to try moving to one of the 7.5.x builds.

Thanx.

Hopefully your alarm is not trying to play an empty stream - one that usually works but sometimes is working when the alarm goes off. I seem to recall reading of another bug where a deleted alarm would suddenly activate and have experienced this myself at 4:00 AM.

The Boom kind of looks like a fancy clock radio. Expecting it to function like one is controverisal and may reflect a narrow consumeristic viewpoint. If this was considered core functionality, it would probably be fixed already. If it is fixed in the future, you may have to accept other unrelated bugs that come along for the ride.

[kartman_canada]

[09-11-25 07:01:50.5827] Slim::Utils::Alarm::sound (521) Alarm is 110 seconds early/late - ignoring

So there's the reason it didn't go off, for some reason the alarm timer is going off almost 2 minutes later than it should be. Probably we should fix this so alarms that trigger late for whatever reason still go off. But why would it be going off late I wonder? Is your server really online 100% of the time or do you put it to sleep?

OK... This post got me thinking about time issues with running the server within a VM environment. To this point, I've had no problems but alarms rely directly upon the time system of the server.

So, it seems the HW clock and the system time on my VM based server were drifting and, while the VM environment has mechanisms for correcting this, this was the cause of the failed alarms. I've made some changes that make the HW and system times stay more rigidly sycned and this appears to have corrected the issue I was having...

This leads me to a couple of questions:

1) why were the alarms being "skipped" just because they were early/late? This behaviour makes no sense to me as early/late are not good but no alarm is very bad. This should be corrected in the server software, IMHO.

2) The time on the Squeezebox devices and all log entries seem to be keyed off the system time. Why does the alarm system seem to be working with the HW clock? Theoretically, these should be the same, I agree. It's not immediately apparent to a casual user and seems to be counter-intuitive which caused me much delay in focusing in on the real issue.

Thanx to all that took the time to weigh in... I've had no failed alarms since correcting the HW/System time sync issues. I'll continue to monitor things but I'm pretty sure that was the problem.