After snooze, alarm fallback is server-side "slim-backup-alarm" not on-device sound

[slothrop]

My setup:

LMS 8.2.1 on Raspberry Pi
Squeezebox Radio (firmware 8.0.1) connected over wifi


My problem:

The radio's wifi connection is not perfect (although much better since installing wlanpoke), and this can cause problems with alarms.

My daily alarm is currently configured to use one of the "Sounds and Effects" on mysqueezebox.com.

If the wifi connection is down when the alarm first sounds, the radio behaves correctly - i.e. it falls back to the locally stored file at /usr/share/jive/applets/AlarmSnooze/alarm.mp3. That's fine.

However, what sometimes happens is:
1) The alarm initially sounds correctly using the sound on mysqueezebox.com.
2) I snooze the alarm.
3) In the interim, wifi connection seems to be lost.
4) When the snooze interval expires, what sounds is not the locally stored alarm.mp3. It's a sound described on screen as "Backup Alarm", which sounds like a repeated pulse of something like a pure sine wave tone.

Today I had a variant of this, but worse - after the snooze interval expired, no sound played. I overslept, eventually woke up, and at this point when I pressed the pause button on the radio, the "Backup Alarm" started playing.

In the server logs I see:

[23-01-12 06:45:47.9991] Slim::Utils::Alarm::stopSnooze (808) Snooze expired
[23-01-12 06:45:48.0038] Slim::Utils::Alarm::stopSnooze (818) unpausing music
[23-01-12 06:45:48.4254] Slim::Utils::Alarm::_setAlarmSubscription (1204) Adding alarm subscription
[23-01-12 06:45:48.4464] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause
[23-01-12 06:45:48.4511] Slim::Utils::Alarm::_alarmEnd (1981) Ignoring self-created request
[23-01-12 06:45:48.5511] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist stop
[23-01-12 06:46:08.5481] Slim::Utils::Alarm::_checkPlaying (1115) Checking whether client is playing for alarm 05481ca0
[23-01-12 06:46:08.5548] Slim::Utils::Alarm::_checkPlaying (1122) Current playmode: stop
[23-01-12 06:46:08.5957] Slim::Utils::Alarm::_checkPlaying (1125) Alarm active but client not playing
[23-01-12 06:46:08.6021] Slim::Utils::Alarm::_playFallback (1150) Starting fallback alarm: loop://192.168.0.254:9000/html/slim-backup-alarm.mp3
[23-01-12 06:46:09.1399] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist stop

So it appears that this "Backup Alarm" is actually stored on LMS, not on the radio? (192.168.0.254 is the IP of the LMS host).

In the radio logs, I see nothing before 06:47, which makes me suspect the radio crashed. I don't know the cause of that, and of course it might not be related to the use of this server-side backup alarm.


My questions / feature request:

1) Is this use of slim-backup-alarm.mp3 from the server intended, as opposed to falling straight back to the on-device alarm.mp3, which will always be available regardless of wifi state?

2) I'd be quite satisfied if the radio always used its on-device alarm.mp3, and didn't even try to get an audio file from the server or the internet. This doesn't seem to be available as an option when configuring alarms though: it seems like you have to select a playlist or favourite from the server, or a sound from mysqueezebox.com. Could "always use on-device alarm sound" be made an option in future versions of LMS and the radio firmware?

[slothrop]

2) I'd be quite satisfied if the radio always used its on-device alarm.mp3, and didn't even try to get an audio file from the server or the internet. This doesn't seem to be available as an option when configuring alarms though: it seems like you have to select a playlist or favourite from the server, or a sound from mysqueezebox.com. Could "always use on-device alarm sound" be made an option in future versions of LMS and the radio firmware?

For now I was able to do this by hacking AlarmSnoozeApplet.lua (so that _pollDecodeState() just returns self:soundFallbackAlarm()) . It would still be cool if it was configurable!