Bugzilla – Bug 14870
Alarm doesn't work reliably
Last modified: 2010-05-15 18:24:47 UTC
This morning I faced issues with the alarm on Radio, which really annoyed my wife as she didn't knew what to do. I'm currently using 4.7.0, searched bugzilla for all 7.4.1 and 4.7.x-bugs but couldn't find a report. Typically I'm connected to a local SB-Server, but yesterday the server was shut down. We have two alarms sets, both to play an internet-radio-stream (which is in the favourites list). In the night the radio is in standby, showing the big digital clock. Now this is what happened tonight: Alarm #1: was the backup alarm (beeping), pressing the big knob didn't turn it off. Some more buttons were pressed by my wife but alarm couldn't be turned off. When I pressed power on/off it turned off, but my wife said she did that as well without success. I'm sorry not being able to describe more in detail what we did. Alarm #2: Surprisingly this one played the internet radio stream. BUT: the radio did NOT turn on the menu to show the typical options (snooze/alarm off) - there was still the clock showing. Pressing the big know so didn't make a difference, Power On + Power Off turned the alarm off. Choosing Snooze (most important function for my wife) so didn't work in both cases. I tried to reproduce, but my radio still seems to be in an inconsistent state: - Pressing the alarm button, doesn't show the alarm menu - When I go to the menu (settings->alarm) I can shortly see 'connecting to mysqueezebox.com' then I still see the settings-menu with an endless (>10min) spinning wheel. Pressing Back and the menu-option again helped, now with a new alarm, everything works as expected. Trying to enable SSH to download logs, doesn't work as well :( The Menu 'Settings->Advanced' doesn't show any options but 'reset to default'. I will reboot now to see I still can find some log of this morning.
/var/log/messages is strange even more. You see entries from Jan 11, but these entries must be 'new' as I can see some of my Player-names (like 'Arbeitszimmer') in there.
Created attachment 6182 [details] /var/log/messages after a reboot
The issue with the logs initially showing Jan 11 is likely because the RTC (hardware clock) time isn't set correctly, because /dev/rtc0 doesn't exist, which is already being addressed in 7.4.1. I'm not sure what other impact the lack of a correct hwclock would have on this particular issue, I guess it would at least screw up the fallback alarm. Temporarily, you can kill this part of the issue by doing an explicit factory reset on the Radio (settings -> advanced -> restore factory settings). That will fix the hwclock part of it anyways.
As a sidenote: The fallback alarm thankfully rang at the correct time. This leaves the other problem that the Radio didn't turn itself on to show the Snooze/Stop-Alarm Window and the Alarm-Button itself didn't turn on the alarm-menu.
Brandon - I updated the firmware (7907) and rebooted (multiple times). Time is still wrong in the logs during startup. Do I really need to do a factory reset ? Shouldn't the time be synced in a regular interval ?
There was another bug found with the RTC that is more then likely the cause of this. Please upgrade to r7915 and test again.
Richard, apart from the time-issues in the logs ... I hope that you are right that the other issues in the first post are solved as well. Anyway - I'm on 4.7.1 and this morning the alarm started to blast at full volume .. what a shock ! After turning it off the Radio tried to connect to my local SB-Server. As this was turned off already the whole night, it couldn't find it. It didn't ask to switch to MySB.com, in fact - not even in the settings-menu (Advanced->Network) I was able to switch to MySB.com. Also my other trick of selecting Internet-Radio to make him switch didn't work - again the radio wanted to connect to my disconnected local SB-Server. I don't know whether this issues are related to a turned off local SB-Server. But I'd feel more safe if you confirmed that such a scenario is on your test-plans. Don't know how many more mornings I can go on like this, before my wife is kicking the radio out and gets the old alarm clock :(
Richard, did your investigations get any result ? Being on 7.4.1 the alarm didn't work as expected this morning again :(. Here is what happened, sounding quite similar to the situation of the first post: - the SB-server was off yesterday for some time, but was in a working condition the whole night - this morning the first alarm was only the backup alarm (normaly a radio station) - as I knew this could have anything to do with the server I tried to play the radio-station manually. SB-radio said 'connecting to server' and after some seconds the stream started to play. So I went back to sleep. - the second alarm DIDN't fire :((((. Pressing the alarm button didn't work, the menu just didn't turn up. Trying to enable SSH to get the logs didn't work as well ... the popup 'SSH is activated' just didn't turn up - and after a reboot it worked, but the log from this morning was overridden by the reboot. After the reboot I configured a third alarm, this one worked again. Please try to reproduce and fix this issues ! I don't want to post here every second week, just because the SB-server will be down now and then.
Please have a look at Bug 14948, does your IP switch daily as well?
Didn't check but I expect it to change on a daily basis as well. Everything else would be very uncommon here in germany. Can provide you with further information within the next 48 hours ...
I can confirm, that my external IP switches. Yesterday my Router showed 85.178.60.118, today 85.178.14.60
Brandon/Tom: See above, we discussed this in today
Could someone explain why you need a constant IP to the outside world ? Does MySB.com get confused if a radio connects with changing IPs ? Anyway, played around a bit today with the alarm and instantly found two simple scenarios not working correct. All scenarios were tried twice and were reproducable. I'm on 7.4.1 Scenario 1 ========== - network up, sbserver running, radio connected two sb-server - set up two alarms (+5min, +10min), set sound to a favourite/radiostation, put radio to standby - shut down sbserver - wait for first alarm => first alarm blasts with full volume (what a shock even while testing), some music I don't know is playing (not the radio station) but its not the beeping I know - wait for second alarm => second alarm doesn't fire at all ! This scenario very much looks like the situation from comment #7 Scenario 2 ========== - network up, sbserver running, radio connected two sb-server - set up two alarms (+5min, +10min), set sound to a favourite/radiostation, put radio to standby - wait for first alarm => normal operation - shut down sbserver - wait for second alarm => alarm menu pops up, but NO sound at all (waited a minute at least)
Stephan, the external ip address issue appears to affect the general ability to connect to mysb.com (not just for alarms) for as yet not understood reasons. However, that ip address issue doesn't appear to be what the bug is in your described scenarios.
I find it absurd that an alarm clock needs a server! What value does that add? We've seen how it adds risk. Reliability is top priority for an alarm clock. (a 9V battery backup for the Squeezebox radio alarm would have also been a nice touch...) My (piece of crap)$20 old clock radio has a reliable alarm and a battery backup. I expected no less on my $200 Squeezebox Radio.
QA to reproduce. 1) can't turn off bug 2) in-server backup alarm doesn't work 3) local backup alarm doesn't
Well, I can reliably reproduce SOMETHING. It may or may not lead to the root cause of the problems people are reporting, but it's worth looking into. Steps: 1) Factory reset 2) Connect to MySB (of course, this is the SB radio after all.) NOTE: do NOT connect to a local SbS 3) Set two alarms: Alarm 1: 5 minutes in the future, source is an invalid radio station. Alarm 2: 7 minutes in the future, source is one of the built-in sounds. 4) 1st alarm triggers. There is a delay, then the primitive alarm beep plays. 5) Hit snooze. 6) 2nd alarm triggers. The alarm sound plays. 7) Hit snooze. 8) NOTE the 1st alarm stops triggering after this point. 9) 2nd alarm triggers again. Hit snooze again if you feel like. Max, could I interest you in looking at this? Or is this something specific to the radio, or more in the field of one of our developers? Thanks!
Chris, I don't get your point 2) Why don't you test with a SbS and just with MySB.com ? I'd be very interested if someone could verify the buggy behaviour described in comment #13, or if this just happens to me ?
I tried to reproduce it with a local server and couldn't. :(
(In reply to comment #19) > I tried to reproduce it with a local server and couldn't. :( are you on 7.4.1 or latest 7.5 ?
I only tried 7.4.1
(In reply to comment #21) > I only tried 7.4.1 Really strange. So at least there's a parallel universe where its working ;) Guess I need to find other clues ... will try over the weekend.
Hi Chris, found some time to retry and debug both scenarios from comment #13 very deeply. From looking at the source-code I cannot understand how you couldn't reproduce scenario1. The second scenario is a bit strange, but I hope with the provided logs you get some ideas what could be wrong there. I'll try to be as concise as possible in describing what I did. So here we go: Preparation ============ - I'm still testing with a 7.4.1 SB-Server and radio with corresponding firmware (r7915) - I did a fresh factory reset, chose english as language, disabled all sound effects (Settings->Audio Settings->Sound Effects) - Activated SSH connection (settings -> advanced -> remote Login) - Went to 'My Music' and am asked to connect to my local SB-Server. Did so. - Connected via SSH, created a /media/logs/log folder (sort of faking an SD-Card on the radio). After a restart I can go to the advanced-settings-menu and am able to activate some debug-levels (audio.decode for scenario 1+2) ==================================== Scenario 0, a.k.a "Normal Operation" ==================================== Just to have something to compare, see provided log 'scenario0 - normal operation.txt' - 12:06 setting alarm to 12:08 and 12:10. I can see in the logs and sourcecode, that RTC-alarm timer is configured ("AlarmSnoozeApplet.lua:95 storing epochseconds of next alarm: 98000") - 12:08 first alarm goes off and playing radio station I can see in the logs, that the RTC-alarm is configured to the next alarm (at 12:08:21) - 12:10 second alarm goes off and playing radio station ======================================================= Scenario 1, a.k.a. "SB-Server down before first alarm" ======================================================= See provided log 'scenario1 - sbs down before first alarm.txt' 13:57 setting alarm to 13:59 + 14:00 13:58 sbs server turned off 13:59 backup alarm 'applets/AlarmSnooze/alarm.mp3' is playing at full volume. Looking at the source-code this is no wonder. Volume is just set to an arbitary loud value (decode:audioGain(4096, 4096) in line 196 of AlarmSnoozeApplet) for the RTC-alarm. You should really try this out in a silent bed room lying beside the radio. It's blasting you away ! Hope noone dies because of a heart attack. 14:00 second alarm doesn't go off When looking in the logs, I miss that after the first backup-alarm fired, the RTC-alarm isn't reset like in scenario0 and 2. So its no wonder that the second alarm isn't firing. How can this work for you Chris ? ======================================================= Scenario 2, a.k.a. "SB-Server down after first alarm" ======================================================= See provided log 'scenario2 - sbs down after first alarm.txt' 13:04 alarm set to 13:05 and 13:07 13:05 first alarm goes off, in the logs you can see the volume fading in. The RTC timer of the second alarm is set (at 13:05:20) 13:06 SB-Server turned off 13:07 second alarm goes off -> I can see an alarm popup but there is no sound. In the logs we see, that the RTC-alarm goes off and also starts to play a sound. I'm confused about the following line in the log: Nov 15 13:07:00 squeezeplay: DEBUG audio.decode - decode_resume_decoder_handler:117 resume_decoder decode state: 1 audio state 0 'audio state' is 0 - in all the other logs you will find the 'audio state' at 40 when sound is playing. I this the key to not playing any sound at all?
Created attachment 6307 [details] scenario0 - normal operation.txt
Created attachment 6308 [details] scenario1 - sbs off before first alarm.txt
Created attachment 6309 [details] scenario2 - sbs off after first alarm.txt
Sorry to bother you again, but didn't wake up this morning (should I mention that I'm angry again) so here we have a new candidate: ================================== Scenario 3 - a.k.a "Local Server running, but having problems playing stream" ================================== For this to be reproducable you need a server that throws an error when trying to play a stream. This can easy be made reproducable, when your server - runs on a linux machine - and you remove read/write right to the /tmp + /var/tmp directory (restart server afterwards) - and you play a radio-station which is WMA-encoded (please note that this strange setup is just to create a reproducable error) I rebooted the radio to make sure, this is not just a variation of scenario2. - create an alarm, set it to play a Windows Media radio-stream - when the alarm goes off, you see the menu, but there is NO sound at all. - have your wife wake you up an hour late In the serverlogs you will find the following error at the alarm time: ------------ [09-11-16 22:11:34.6655] Slim::Networking::IO::Select::__ANON__ (146) Error: Select task failed calling Slim::Networking::Async::HTTP::_http_read_body: Error in tempfile() using ./XXXXXXXXXX: Parent directory (./) is not writable at /usr/share/perl5/Slim/Utils/Scanner/Remote.pm line 542 ; fh=Slim::Networking::Async::Socket::HTTP=GLOB(0x2dbe478) ----------- Does it make sense to split up this report for the single scenarios or do you want to keep them here mixed ?
One alarm starting will cancel prior alarms so the behavior described by Chris in comment 17 is by design. I'm afraid I don't have the time to devote to chasing this bug. Stefan's last scenario sounds entirely plausible. The alarm has code to check that something is playing, but I don't know what status would be returned in those sort of situations. Alan may be a good candidate to comment on this.
Ben after our conversation this morning, should this be assigned to you?
sure. technically this is a 7.4.x bug, so targetting it as such.
hope this doesn't mean its a lower priority now because 7.5 needs to get ready first. Please tell me I'm just paranoid.
My Radio alarm has been very unreliable. I don't know that it's the same as described by others in this thread, but I believe it's a very straightforward use case. I am running V7.4.2 on a Linux (Ubuntu) SBS server which runs 24/7. The Radio's alarm was a single alarm, set to go off every weekday morning. The selected alarm sound is from the "sound effects", so I guess that requires connection to mysb.com. I would say in a typical week, the alarm doesn't sound about 2 times out of 5. The Radio seems to "think" the alarm is working - it displays the dialog to snooze or turn off the alarm, but no sound is playing. I will change the sound to a file stored locally to see if that improves the reliability. I have to say that for a product which is obviously intended to be used as a bedside radio/alarm, the alarm function reliability should be a HIGH priority. Also, would it be possible to select an alarm sound which is actually stored on the Radio itself, so it wouldn't require ANY network to sound an alarm? (I know this isn't the way the Radio needs to be connected, but if something goes south on a network over night, or the server has problems, internet issue, etc, the alarm could still sound)...
Background: I'm always and only using last.fm's Tag radio and do not have a standalone SB Server running in my appartment. OK, I could supply another piece of logfile. The minor problem may be that I cannot exactly remember what happened in detail (I was still half asleep). Any way, I hope it was not a dream but a fact that I heard the SBRadio turn on and slowly increase the volume up to the alarm level. Afterwards the song was cut off quite roughly which I thought could have been caused by last.fm. So I waited for a few seconds. Obviously with no result because the next thing I heard was my primitive, old-school fallback alarm radio which perfectly woke me up half an hour later. The interesting thing, however: When I looked at the SBRadio, there was still the alarm popup displayed, just as it would be playing somethings right at that moment. Enormously annoyed, I turned it off. When pusing the button, a song was audible for a split-second until the popup disappeared and the standby clock was on the display again. I am not sure whether the log file snippet (sb_silent_alarm.txt) has any use for you pros, but I'd like to provide any support possible. As soon as I have more time, I also will do more in-depth testing. This alarm issue is critical and nearly renders the SBRadio useless in my eyes. (And I don't want to even mention that the device does cost quite some money.)
Created attachment 6371 [details] snippet covering the time during the "silent" alarm
Just to add my voice - for some reason the SBRadio lost connection to the server overnight and I had the silent alarm problem this morning. The alarm is set to go off each weekday at 8:30 and stream the internet radio stream 'FIP'. I had my laptop next to the radio while it was struggling to connect and there was no problem connecting to the wireless, my SBS, the internet nor my audio connnection, so I can confirm that there were no *real* problems with the network nor the server, but SBRadio could not connect for whatever reason. However, it did not trigger an error and therefore the backup alarm was not triggered. I suspect the wireless hardware/driver within the radio, combined with bad error trapping to catch the situation when it fails. I have since upgraded the firmware as a result and its currently playing the stream again. It seems the problem is that if the sream / connection is lost the Alarm doesn't go into an error state and therefore trigger the backup alarm sound. No logs I'm afraid, but it is the same symptoms as described before, and the alarm was working fine for about a week before this.
*** Bug 15319 has been marked as a duplicate of this bug. ***
== Auto-comment from SVN commit #8237 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8237 == Bug: 14870 Description: make RTC fallback alarm running at all times instead of only when server is detected as disconnected assumption is that notify_serverDisconnected and notify_serverConnected are not always trustworthy sources of information when alarm time hits and server is connected, two things should happen-- RTC timer should timeout and attempt to fire the alarm, and server should send a notification that the alarm is active and attempt to fire the alarm. Whichever one loses that race will simply not do anything. Whichever one wins that race will see if the player is connected and fire the appropriate alarm (if connected, audio from server/network, if not, local fallback alarm) this bug is not fixed, but is the first in hopefully a series of checkins between now and xmas to harden this feature.
== Auto-comment from SVN commit #8245 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8245 == Bug: 14870 Description: when radio is controlling another player and local alarm fires, more intelligently change the controlled player back to the radio do not use self.player in AlarmSnooze as it is a confusing object in this applet. Instead use self.localPlayer where needed.
flagging critical bugs for SB Radio with keyword radioAlarmsCritical
I took some time to test my scenarios (see comment#23 and comment#27) against Bens latest changes and also against the changed applet provided in the forums by Marc. Here are my test results: Marcs applet with 4.7.1 ======================= (SB-Server 4.7.1 with applet from http://forums.slimdevices.com/showthread.php?p=501012 copied to radio): scenario 0: works scenario 1: not tested (as secondary alarm is out of focus, when server is down on the first) scenario 2: on second alarm the popup shows and the backup-mp3-alarm is playing (yeah) - so this problem has been fixed Please note, that I still think that the backup-mp3-alarm needs to fade-in ! It's shocking loud in the night with the radio right beside your ear scenario 3: still not working - popup appears but no sound is playing SB-Server 4.7.x Nightly ======================== (SB-Server 29707/jive 8264 - should contain all of Bens changes) scenario 0: alarm popups appears, internet radio starts to play. Hitting 'stop alarm' in the menu shows the popup 'stopping alarm', but the streams doesn't stop to play. I have to hit the pause button in addition. => New Regression Bug introduced. :(( scenario 1: not tested, see above scenario 2: still not working - on second alarm there is a popup, but no sound scenario 3: still not working - popup appears but no sound is playing Please note, that when using Marcs-Applet with 4.7.2 Nightly, scenario 0 shows the same regression bug. So I guess this must have been introduced on the server side ? My Conclusion ============== 7.4 nightly introduced a new regression bug for scenario 0 "normal operation" Marcs applets solves scenario 2 "SB-Server down after first alarm", so I hope his changes are reviewed and included in future releases
Update to accomodate Marcs latest changes: SB-Server 29707/jive 8264 + Marcs applet ========================================= (applet from http://forums.slimdevices.com/showthread.php?p=501944): scenario 0: works (still with 7.4.2 regression bug, that alarm doesn't stop when selecting the option from the alarm popup) scenario 1: not tested (as secondary alarm is currently out of focus, when server is down on the first) scenario 2: fixed (alarm popup comes with a slight delay and alarm.mp3 is playing) scenario 3: fixed (alarm.mp3 playing when there is a corrupt/no stream)
>Hitting 'stop alarm' in the menu shows the popup 'stopping alarm', but the > streams doesn't stop to play. >I have to hit the pause button in addition. > => New Regression Bug introduced. you may not agree with this, but this is intentional and not a regression. See bug#14578
Ben, I can't get the reasoning behind this decision (unfortunately the bug report just states 'change it', without giving use cases and intention). I don't want start a discussion in this bug, nor annoy you with reopening the other bug (or creating a new one like 'revert old behaviour'). Anyway as I think this change is a plain wrong decision, not being intuitive and will confuse a lot of users (like my, mnyb and marc already). To go on I started a discussion on the forum: http://forums.slimdevices.com/showthread.php?p=502395
== Auto-comment from SVN commit #8285 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8285 == Bug: 14870 Description: add isStreaming() method to LocalPlayer object
== Auto-comment from SVN commit #8286 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8286 == Bug: 14870 Description: _stopInternal() is called from outside Playback, so rename it stopInternal() add an optional skipDelay param to LocalPlayer:stop() so stopInternal() gets called immediately when desired, not on a 400ms delay
== Auto-comment from SVN commit #29756 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29756 == Bug: 14870 Description: Squeezeplay-based players will handle the 20 second fallback check on the client-side
== Auto-comment from SVN commit #8312 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8312 == Bug: 14870 Fixed Bug: 15457 Description: first checkin of merged code that includes Marc's code to defensively fire the fallback when things go bad and many other changes made by me -- include a sending of a WOL packet 10 mins before next configured alarm -- alarm window now has an EVENT_WINDOW_POP listener that resets the self.alarmInProgress value when the window hides. This effectively ties resetting of state variables to the popup window while allowing events to bubble up the event handler (i.e., return EVENT_UNUSED on callback actions) -- for now the sledgehammer method is only called by the decodePollTimer and not by the misc notification methods. My hope is that's what we can eventually settle on.
== Auto-comment from SVN commit #8317 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8317 == Bug: 14870 Description: For now, pull all log messages out of (if self.localPlayer) clauses. remove 59 second alarm window hide timer remove streamSuccessChecker, as it is replaced by the decodeState poller
== Auto-comment from SVN commit #8320 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8320 == Bug: 14870 Description: use decode:status().audioState to check if something's currently playing. LocalPlayer:isStreaming() is not the correct check, nor is decode:status().decodeState
*** Bug 15201 has been marked as a duplicate of this bug. ***
== Auto-comment from SVN commit #8331 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8331 == Bug: 14870 Description: Use decode:status().audioState as the gold standard for deciding if audio is coming out the speakers. In my tests this reliably works for both streaming audio and the client-side fallback alarm. I believe this checkin may fix the reliability issues such that a user should be able to depend on something to wake them up at alarm time. I will fall short of calling this bug fixed, but let's call it "Release Candidate 1" :)
== Auto-comment from SVN commit #8332 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8332 == Bug: 14870 Description: if server comes back after rtc alarm has fired, call the sledgehammer to make sure audio continues to pipe out the speaker.
== Auto-comment from SVN commit #29813 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29813 == Bug: 14870 Description: make sure squeezeplay revision is >= r8312 when removing the 20 second server-side fallback alarm
== Auto-comment from SVN commit #8338 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8338 == Bug: 14870 Description: make sure self.alarmInProgress is set before restarting the alarm timer in sledgehammer
== Auto-comment from SVN commit #8339 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8339 == Bug: 14870 Description: patch from bluegaspode (thanks) that does a cleaner method call when back button is hit
== Auto-comment from SVN commit #8343 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8343 == Bug: 14870 Description: in the event of an alarmState notification for the local player and no rtc alarm currently firing, the alarm window should hide if alarmState is 'active', a new one will be brought to screen
== Auto-comment from SVN commit #8360 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8360 == Bug: 14870 Description: don't ignore volume_up and volume_down actions
== Auto-comment from SVN commit #8370 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8370 == Bug: 14870 Description: restart decodeStatePoller regardless of caller to openAlarmWindow()
== Auto-comment from SVN commit #8375 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8375 == Bug: 14870 Description: - allow Player:alarmStop() to be executed when self.alarmState is not 'active' - 9 minute snooze timer is set on a snooze event regardless of what type of alarmInProgress it is. - self.alarmInProgress is explicitly set to 'snooze' when the snooze command is sent - self.alarmInProgress is explicitly set to 'snooze' on an alarmState notification of 'snooze' - serverDisconnected notification is now set to not fire a fallback alarm when alarmInProgress is set to snooze (instead, wait for the snooze timer to expire)
== Auto-comment from SVN commit #8376 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8376 == Bug: 14870 Description: accidentally missed this part in the last checkin - allow Player:alarmStop() to be executed when self.alarmState is not 'active'
== Auto-comment from SVN commit #8381 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8381 == Bug: 14870 Description: with removal of 59 second automatic window hide, time should again be updated in the alarm window as minutes change
As I did a lot of testing today, as a snapshot here are the current results: Testet with server 7.4.2 r29879, radio firmware r8381 (this is the latest officially pushed firmware) - scenario 0 "Normal Operation" : works - scenario 1: not tested as no work done on this one yet - scenario 2 "SB-Server down after first alarm": fallback works - scenario 3 "Local Server running, but having problems playing stream": fallback works For reference here are some new snooze scenarios. Snooze timeout on server is set to 3 minutes. ======================================================================= scenario 4: server on at alarm, but off/on while snooze alarm is playing ======================================================================= 15:00 alarm set to 15:05 15:05 alarm goes off, user hits 'Snooze' 15:08 snooze alarm goes off 15:09 server stopped => stream is replaced by fallback alarm :) 15:10 server (re)started => fallback stream stops, popup still open :( Cause: the radio gets an 'alarmstate=set', all timers are reset, including the sledgehammer timer (which tried to reastablish audio after 1,5 seconds) => there needs to be code that saves the 'alarmstate=set' directive when there is an RTC-alarm going on until the RTC-alarm is stopped ? Variation A: - if I instead just disconnect/connect the server-network, the fallback does not stop at 15:10 ======================================================================= scenario 5: server on at alarm, but off before snooze alarm ======================================================================= 15:00 alarm set to 15:05 15:05 alarm goes off, user hits 'Snooze' 15:06 server disconnects/stopped 15:08 (no snooze alarm) 15:14 snooze fallback alarm starts => we don't have a snooze alarm at the right time, but after 9minutes a fallback alarm starts instead ================================================================= scenario 6: server on at alarm, but off/on before snooze alarm ================================================================= 15:00 alarm set to 15:05 15:05 alarm goes off, user hits 'Snooze' 15:06 server disconnects/stopped 15:06 server restarted 15:08 (no snooze alarm) 15:14 (no snooze fallback alarm) => As in Scenario 4: When the server is restarted it resets all alarm-state. Snooze-Alarm is lost :( =================================================== scenario 7: server off before alarm and snooze =================================================== 15:00 alarm set to 15:05 15:02 server disconnects/stopped 15:05 fallback alarm goes off, user hits 'Snooze' 15:08 (no snooze alarm) 15:14 fallback snooze alarm starts Things achieved: - connection losses (SB-server or audio-streams) are handled pretty stable now in all scenarios Things still open: - server restart kills running alarm - server restart kills a snoozed alarm - snooze timeout >=9 min always leads to fallback alarm for the snooze alarm after 9minutes - pressing back button doesn't tell server alarm is off (fix already proposed by marc) - (fallback alarm should fade in)
apologies on the forum thread, but I'm not going to reply for a little while I execute test cases. The volume of posts from the weekend are far beyond my means to digest right now. some comments on your last post: Things still open: - server restart kills running alarm - server restart kills a snoozed alarm I'll put some added focus on this today. I'm running my own matrix of test cases which for the most part have been behaving well with server disconnects. I'll run through your test cases as well now. - snooze timeout >=9 min always leads to fallback alarm for the snooze alarm after 9minutes I've added 10 seconds to the fallback alarm timer on snooze and that's basically fixed the issue, at least when snooze timeout is set to default of 9 minutes. The snooze timeout pref needs to be communicated from the server to the client so the player object has this value stored for reference. After that, the 9 minute hard-coded issue will be trivial to fix. For now though, the expectation is a 9 minute snooze (server default). - pressing back button doesn't tell server alarm is off (fix already proposed by marc) That behavior is by design. The back button doesn't turn the alarm off. - fallback alarm should fade in Sorry, but that's out of scope with the 7.4.2 and IMO an enhancement request.
== Auto-comment from SVN commit #29902 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29902 == Bug: 14870 Description: do not immediately sound alarms for that minute when executing scheduleNext()
>> The volume of posts from the weekend are far beyond my means to digest right now. Fair enough: here is a summary http://forums.slimdevices.com/showthread.php?p=510405&postcount=241 so that we can continue discussions in the forum and don't pollute the bug-report. (If I missed anything, I'm sure Marc will comment) >> fallback alarm should fade in created a feature requests - watchers please vote :) https://bugs-archive.lyrion.org/show_bug.cgi?id=15534
== Auto-comment from SVN commit #29914 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29914 == Bug: 14870 Description: remove "Alarm Stopped" showBriefly from server for squeezeplay devices
== Auto-comment from SVN commit #8401 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=8401 == Fixed Bug: 14870 Description: This checkin has been tested against a set of 11 test cases and passed all of them executive UI decision: button actions other than 'go', 'back', 'mute', 'volume_up', 'volume_down', 'power', and 'pause' are consumed when the alarm window is active remove window listener for EVENT_WINDOW_POP, as it now serves no purpose (because of executive UI decision) self.alarmInProgress remains 'rtc' when snooze is hit make sure sledgehammer is true when it needs to be clean up code obey server-side setting for alarmSnoozeSeconds by adding a player method Player:getAlarmSnoozeSeconds(). Defaults to 540 seconds (9 minutes) add 20 seconds to snooze fallback timer to give server the chance it needs to fire alarm after snooze expires add a status poller for debug (disabled by default)
== Auto-comment from SVN commit #29918 to the slim repo by bklaas == == https://svn.slimdevices.com/slim?view=revision&revision=29918 == Bug: 14870 Description: send alarm_snooze_seconds in playerstatus update allow setting of player prefset of alarmSnoozeSeconds to pass through the filter and auto-generate a playerstatus notification
(In reply to comment #32) > My Radio alarm has been very unreliable. I don't know that it's the same as > described by others in this thread, but I believe it's a very straightforward > use case. > I am running V7.4.2 on a Linux (Ubuntu) SBS server which runs 24/7. The > Radio's alarm was a single alarm, set to go off every weekday morning. The > selected alarm sound is from the "sound effects", so I guess that requires > connection to mysb.com. > I would say in a typical week, the alarm doesn't sound about 2 times out of 5. > The Radio seems to "think" the alarm is working - it displays the dialog to > snooze or turn off the alarm, but no sound is playing. > I will change the sound to a file stored locally to see if that improves the > reliability. > I have to say that for a product which is obviously intended to be used as a > bedside radio/alarm, the alarm function reliability should be a HIGH priority. > Also, would it be possible to select an alarm sound which is actually stored on > the Radio itself, so it wouldn't require ANY network to sound an alarm? (I know > this isn't the way the Radio needs to be connected, but if something goes south > on a network over night, or the server has problems, internet issue, etc, the > alarm could still sound)... I can confirm that this still periodically occurs on the Radio (all firmware up-to-date). It usually seems to happen on a second alarm (i.e. we have two alarms set 1 hour apart; the second one occasionally shows the slumber/cancel screen but emits no noise (in fact of course it shuts off the stream that was playing). I wonder if the alarm software is not too complex, to be honest. Getting something to launch at a set time shouldn't be this hard, it seems to me.
Most mornings the alarm will connect to the radio station, and play normally, we hit the snooze, and nine minutes later, the radio station comes back on, and we eventually get up. Lately however, the alarm will fail to connect to the radio station and the back up alarm will come on. Then we hit the snooze and sometimes it comes back on in nine minutes, sometimes not. After we get up, I check the station and it always connects right away. Several times the snooze worked once or twice before failing. We rarely have the home computer on, so the Boom is connected directly to the internet via the wifi. I realize this doesn't give you much specific information, but it's all I have. The only thing we really change from day to day is the wake time, and really that doesn't change all that much.
Using the Squeezebox Boom. When waking to an alarm set using the mysqueezebox.com the alarm goes on fine, but when the alarm is scheduled to go off it goes off only briefly (a few seconds) then comes back on and stays on unless I manually turn it off. I have two alarms set, but they do not overlap. The Boom has the latest firmware (50).
This bug has been fixed with concrete changes to the code. If you are still experiencing problems, please file a new bug. Thanks!
(In reply to comment #72) > This bug has been fixed with concrete changes to the code. If you are still > experiencing problems, please file a new bug. Thanks! B/U Alarms fails on Battery. See Bug 16230 Tony