Alarm not working with 8.3?

[slartibartfast]

You asked me to try this a week ago and it did cancel the alarm, I couldn’t get the fallback. So at least the behaviour was already like this on 8.3.1 before the Alarm fix was applied

Did you try pausing the alarm. I get the fallback after 2 minutes now [emoji3]

Sent from my Pixel 3a using Tapatalk

[KeBul]

> So it looks like the behaviour of pressing pause from a remote control
> device has changed.

But the change would be in 8.3.0, too?

First of all apologies to anyone who read my previous responses to this (both posts now deleted, to avoid any confusion) - I jumped the gun somewhat and the information in those posts was not correct.

The testing I'd done and results I had got very much made it look like the pause issue was purely due to the 'playerprefs" fix in the 29th Nov nightly, however, I'd forgotten it can take a while of playing around in Material to start producing failures and during more extensive testing looking at Slarti's "Stop" failures, I've reproduced the pause issue in the 21st Nov nightly as well.

I've been back on 8.3.0 for a while and have just managed to get a pause failure to occur on that as well, so the answer to Michael's question above is yes such failure can occur in 8.3.0!!

What was odd was it was failing every time with a remote device pause when I was testing the 29th Nov nightly this morning, but has been difficult to get it to fail this evening on the previous versions.

However, I've just gone back to 8.3.1 29th Nov nightly - and straight away pause from a remote controller fails to shut of the alarm, so I feel there's definitely something about the 'playerprefs' fix that makes that failure permanent - I'm pretty sure I've not seen it work, as stated in my testing report it failed on every remote control device I tried.

At the moment I would say the change in code fixes or at least drastically improves the problem where an alarm fails to trigger, but completely breaks stopping the alarm with a pause or stop from a remote controlling device.

Kev

[mherger]

Alarm not working with 8.3?

> At the moment I would say the change in code fixes or at least
> drastically improves the problem where an alarm fails to trigger, but
> completely breaks stopping the alarm with a pause or stop from a remote
> controlling device.

Thank you very much for all the work you've done on this subject! This
pretty much is the summary I wanted to ask for after seeing all the
other postings (yours and those of the others involved here).

I'd rate the "don't miss an alarm" much more important than pausing an
alarm from another device. As I would assume most people using an alarm
a.) are using it on a Radio and b.) would use the device's UI to end an
alarm. So overall we got an improvement over 8.3.0?

[slartibartfast]

At the moment I would say the change in code fixes or at least drastically improves the problem where an alarm fails to trigger, but completely breaks stopping the alarm with a pause or stop from a remote controlling device.

Kev

In my system pressing "Stop" in Material does cancel the alarm which it never did before the latest changes so are we still seeing different behaviour?

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

In my system pressing "Stop" in Material does cancel the alarm which it never did before the latest changes so are we still seeing different behaviour?

Sent from my Pixel 3a using Tapatalk

Having said that I tried cancelling the alarm this morning by pressing "Stop" in Material and the alarm didn't cancel and the fallback alarm sounded a little later.

Sent from my Pixel 3a using Tapatalk

[gordonb3]

Does anyone actually have even a start of a clue why 'stop' is called directly after alarm is registered as its handler? It seems more reliable to stop that unwanted behavior rather than maintaining a list of exceptions to which calls should be processed.

[KeBul]

In my system pressing "Stop" in Material does cancel the alarm which it never did before the latest changes so are we still seeing different behaviour?

In this instance maybe slightly different, although I've not tested thoroughly with Stop, in my case, on the 29th Nov nightly, so far every pause from default WebUI, Material, iPeng or jive fails to properly stop the alarm.

Having said that I tried cancelling the alarm this morning by pressing "Stop" in Material and the alarm didn't cancel and the fallback alarm sounded a little later.

Exactly, and that completely unpredictable behaviour is what is making it so difficult to test and resolve.

Kev

[KeBul]

I'd rate the "don't miss an alarm" much more important than pausing an
alarm from another device. As I would assume most people using an alarm
a.) are using it on a Radio and b.) would use the device's UI to end an
alarm. So overall we got an improvement over 8.3.0?

Absolutely, on the 29th Nov nightly I'm certain I've not seen a fail to trigger in several days of testing - must be getting on for over 60 successful alarms now.

If stopping the alarm needs to be done remotely - powering off the player still works fine.

Kev

[slartibartfast]

In this instance maybe slightly different, although I've not tested thoroughly with Stop, in my case, on the 29th Nov nightly, so far every pause from default WebUI, Material, iPeng or jive fails to properly stop the alarm.


Exactly, and that completely unpredictable behaviour is what is making it so difficult to test and resolve.

Kev

It would be nice to get consistent behaviour with pause and stop but like Michael says most times the alarm will be cancelled on the device.
I just tried pausing an alarm from the default skin and heard a snippet of the fallback alarm as the clock reached 10:21 followed by a full fallback alarm at 10:22. That matches your description in an earlier post today.

Sent from my Pixel 3a using Tapatalk

[SamY]

Just to add another usage case, my morning alarm is set up for a stereo pair of Google Nest Minis using Philippe's Castbridge plugin. The alarm had become unreliable in recent months but has not failed since applying the most recent updates to Material Skin and LMS. Following is a debug log of this morning's successful alarm trigger and subsequent successful pause/stop, which was achieved by saying "Google, stop the music". Note that the source for the pause request is "CLI".

[22-12-01 08:30:00.0162] Slim::Utils::Alarm::sound (516) Alarm triggered for Bedroom pair
[22-12-01 08:30:00.0175] Slim::Utils::Alarm::sound (560) Sounding alarm
[22-12-01 08:30:00.0200] Slim::Utils::Alarm::sound (589) Current Power State: On
[22-12-01 08:30:00.0210] Slim::Utils::Alarm::pushAlarmScreensaver (1839) Attempting to push into alarm screensaver: . Current mode: INPUT.List
[22-12-01 08:30:00.0215] Slim::Utils::Alarm::sound (609) Current vol: 32 Alarm vol: 30
[22-12-01 08:30:00.0220] Slim::Utils::Alarm::sound (612) Changing volume from 32 to 30
[22-12-01 08:30:00.0236] Slim::Utils::Alarm::sound (622) Alarm playlist shufflemode: 0
[22-12-01 08:30:00.0249] Slim::Utils::Alarm::sound (628) Alarm playlist url: http://www.folkalley.com/membership.pls
[22-12-01 08:30:00.0366] Slim::Utils::Alarm::_setAlarmSubscription (1204) Adding alarm subscription
[22-12-01 08:30:00.0374] Slim::Utils::Alarm::sound (697) Scheduling time out in 3600 seconds
[22-12-01 08:30:00.0379] Slim::Utils::Alarm::_startStopTimeCheck (1880) 0 scheduled alarm(s)
[22-12-01 08:30:00.0382] Slim::Utils::Alarm::_startStopTimeCheck (1889) Stopping time checker task
[22-12-01 08:30:00.0387] Slim::Utils::Alarm::scheduleNext (1391) Asked to schedule next alarm for Bedroom pair
[22-12-01 08:30:00.0391] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 8:30:0 1/12/2022
[22-12-01 08:30:00.0394] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 8:30:0 1/12/2022
[22-12-01 08:30:00.0396] Slim::Utils::Alarm::findNextTime (471) Skipping..
[22-12-01 08:30:00.0399] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 8:30:0 2/12/2022
[22-12-01 08:30:00.0402] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 8:30:0 1/12/2022
[22-12-01 08:30:00.0405] Slim::Utils::Alarm::scheduleNext (1424) Next alarm is at 8:30:0 2/12/2022
[22-12-01 08:30:00.0408] Slim::Utils::Alarm::scheduleNext (1435) Scheduling alarm
[22-12-01 08:30:00.0411] Slim::Utils::Alarm::_startStopTimeCheck (1880) 1 scheduled alarm(s)
[22-12-01 08:30:00.0413] Slim::Utils::Alarm::_startStopTimeCheck (1884) Starting time checker task
[22-12-01 08:30:00.0430] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: stop
[22-12-01 08:30:00.0445] Slim::Utils::Misc::msg (1325) Warning: [08:30:00.0442] (
  bless({
    _cb_args      => undef,
    _cb_enable    => 1,
    _cb_func      => undef,
    _clientid     => "cc:cc:4c:51:85:cb",
    _func         => sub { "???" },
    _isQuery      => 0,
    _langoverride => undef,
    _needClient   => 1,
    _params       => {},
    _request      => ["stop"],
    _requeststr   => "stop",
    _results      => {},
    _source       => "ALARM",
    _status       => 10,
    _useixhash    => 0,
  }, "Slim::Control::Request"),
  "Alarm: ignored event",
) at /Slim/Utils/Alarm.pm line 1981.
[22-12-01 08:30:00.0448] Slim::Utils::Alarm::_alarmEnd (1982) Ignoring self-created request
[22-12-01 08:31:30.0468] Slim::Utils::Alarm::_checkPlaying (1115) Checking whether client is playing for alarm 36ec2f69
[22-12-01 08:31:30.0475] Slim::Utils::Alarm::_checkPlaying (1122) Current playmode: play
[22-12-01 09:12:03.2180] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause
[22-12-01 09:12:03.2200] Slim::Utils::Misc::msg (1325) Warning: [09:12:03.2198] do {
  require MIME::Base64;
  require Symbol;
  my $a = bless({
    _ae_callback  => sub { "???" },
    _cb_enable    => 1,
    _clientid     => "cc:cc:4c:51:85:cb",
    _connectionid => bless(Symbol::gensym(), "IO::Socket::INET"),
    _func         => sub { "???" },
    _isQuery      => 0,
    _langoverride => undef,
    _needClient   => 1,
    _params       => {
                       # tied Tie::IxHash
                       _fadein => undef,
                       _newvalue => undef,
                       _suppressShowBriefly => undef,
                     },
    _request      => ["pause"],
    _requeststr   => "pause",
    _results      => {
                       # tied Tie::IxHash
                     },
    _source       => "CLI",
    _status       => 10,
    _useixhash    => 1,
  }, "Slim::Control::Request");
  *{$a->{_connectionid}} = {
    _ev_r => bless(do{\(my $o = MIME::Base64::decode("AQAAAAAAAAAAAAAAAQAAAIx0tAVkLCwOpAAeDgQkFA4AAAAAzCzRdAAAAAAVAAAAAQAAAA=="))}, "EV::IO"),
    _ev_w => bless(do{\(my $o = MIME::Base64::decode("AQAAAAAAAAAAAAAAAQAAAIx0tAWceqIMlOEeDpzHSQ0AAAAAzCzRdBwJRA4VAAAAAgAAAA=="))}, "EV::IO"),
    io_socket_peername => pack("H*","0200dd90c0a8010e0000000000000000"),
    io_socket_timeout => "0.001",
  };
  ($a, "Alarm: fired event");
} at /Slim/Utils/Alarm.pm line 1991.
[22-12-01 09:12:03.2203] Slim::Utils::Alarm::_alarmEnd (1992) Unknown source: CLI
[22-12-01 09:12:03.2205] Slim::Utils::Alarm::_alarmEnd (2002) Stopping alarm
[22-12-01 09:12:03.2211] Slim::Utils::Alarm::popAlarmScreensaver (1866) Attempting to pop alarm screensaver.  Current mode: INPUT.List
[22-12-01 09:12:04.2183] Slim::Utils::Alarm::__ANON__ (896) Restoring pre-alarm volume level: 32
[22-12-01 09:12:04.2198] Slim::Utils::Alarm::__ANON__ (901) Restoring pre-alarm shuffle mode: 0
[22-12-01 09:12:04.2206] Slim::Utils::Alarm::__ANON__ (905) Restoring pre-alarm power state: on

[slartibartfast]

Just to add another usage case, my morning alarm is set up for a stereo pair of Google Nest Minis using Philippe's Castbridge plugin. The alarm had become unreliable in recent months but has not failed since applying the most recent updates to Material Skin and LMS. Following is a debug log of this morning's successful alarm trigger and subsequent successful pause/stop, which was achieved by saying "Google, stop the music". Note that the source for the pause request is "CLI".

[22-12-01 08:30:00.0162] Slim::Utils::Alarm::sound (516) Alarm triggered for Bedroom pair
[22-12-01 08:30:00.0175] Slim::Utils::Alarm::sound (560) Sounding alarm
[22-12-01 08:30:00.0200] Slim::Utils::Alarm::sound (589) Current Power State: On
[22-12-01 08:30:00.0210] Slim::Utils::Alarm::pushAlarmScreensaver (1839) Attempting to push into alarm screensaver: . Current mode: INPUT.List
[22-12-01 08:30:00.0215] Slim::Utils::Alarm::sound (609) Current vol: 32 Alarm vol: 30
[22-12-01 08:30:00.0220] Slim::Utils::Alarm::sound (612) Changing volume from 32 to 30
[22-12-01 08:30:00.0236] Slim::Utils::Alarm::sound (622) Alarm playlist shufflemode: 0
[22-12-01 08:30:00.0249] Slim::Utils::Alarm::sound (628) Alarm playlist url: http://www.folkalley.com/membership.pls
[22-12-01 08:30:00.0366] Slim::Utils::Alarm::_setAlarmSubscription (1204) Adding alarm subscription
[22-12-01 08:30:00.0374] Slim::Utils::Alarm::sound (697) Scheduling time out in 3600 seconds
[22-12-01 08:30:00.0379] Slim::Utils::Alarm::_startStopTimeCheck (1880) 0 scheduled alarm(s)
[22-12-01 08:30:00.0382] Slim::Utils::Alarm::_startStopTimeCheck (1889) Stopping time checker task
[22-12-01 08:30:00.0387] Slim::Utils::Alarm::scheduleNext (1391) Asked to schedule next alarm for Bedroom pair
[22-12-01 08:30:00.0391] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 8:30:0 1/12/2022
[22-12-01 08:30:00.0394] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 8:30:0 1/12/2022
[22-12-01 08:30:00.0396] Slim::Utils::Alarm::findNextTime (471) Skipping..
[22-12-01 08:30:00.0399] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 8:30:0 2/12/2022
[22-12-01 08:30:00.0402] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 8:30:0 1/12/2022
[22-12-01 08:30:00.0405] Slim::Utils::Alarm::scheduleNext (1424) Next alarm is at 8:30:0 2/12/2022
[22-12-01 08:30:00.0408] Slim::Utils::Alarm::scheduleNext (1435) Scheduling alarm
[22-12-01 08:30:00.0411] Slim::Utils::Alarm::_startStopTimeCheck (1880) 1 scheduled alarm(s)
[22-12-01 08:30:00.0413] Slim::Utils::Alarm::_startStopTimeCheck (1884) Starting time checker task
[22-12-01 08:30:00.0430] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: stop
[22-12-01 08:30:00.0445] Slim::Utils::Misc::msg (1325) Warning: [08:30:00.0442] (
  bless({
    _cb_args      => undef,
    _cb_enable    => 1,
    _cb_func      => undef,
    _clientid     => "cc:cc:4c:51:85:cb",
    _func         => sub { "???" },
    _isQuery      => 0,
    _langoverride => undef,
    _needClient   => 1,
    _params       => {},
    _request      => ["stop"],
    _requeststr   => "stop",
    _results      => {},
    _source       => "ALARM",
    _status       => 10,
    _useixhash    => 0,
  }, "Slim::Control::Request"),
  "Alarm: ignored event",
) at /Slim/Utils/Alarm.pm line 1981.
[22-12-01 08:30:00.0448] Slim::Utils::Alarm::_alarmEnd (1982) Ignoring self-created request
[22-12-01 08:31:30.0468] Slim::Utils::Alarm::_checkPlaying (1115) Checking whether client is playing for alarm 36ec2f69
[22-12-01 08:31:30.0475] Slim::Utils::Alarm::_checkPlaying (1122) Current playmode: play
[22-12-01 09:12:03.2180] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause
[22-12-01 09:12:03.2200] Slim::Utils::Misc::msg (1325) Warning: [09:12:03.2198] do {
  require MIME::Base64;
  require Symbol;
  my $a = bless({
    _ae_callback  => sub { "???" },
    _cb_enable    => 1,
    _clientid     => "cc:cc:4c:51:85:cb",
    _connectionid => bless(Symbol::gensym(), "IO::Socket::INET"),
    _func         => sub { "???" },
    _isQuery      => 0,
    _langoverride => undef,
    _needClient   => 1,
    _params       => {
                       # tied Tie::IxHash
                       _fadein => undef,
                       _newvalue => undef,
                       _suppressShowBriefly => undef,
                     },
    _request      => ["pause"],
    _requeststr   => "pause",
    _results      => {
                       # tied Tie::IxHash
                     },
    _source       => "CLI",
    _status       => 10,
    _useixhash    => 1,
  }, "Slim::Control::Request");
  *{$a->{_connectionid}} = {
    _ev_r => bless(do{\(my $o = MIME::Base64::decode("AQAAAAAAAAAAAAAAAQAAAIx0tAVkLCwOpAAeDgQkFA4AAAAAzCzRdAAAAAAVAAAAAQAAAA=="))}, "EV::IO"),
    _ev_w => bless(do{\(my $o = MIME::Base64::decode("AQAAAAAAAAAAAAAAAQAAAIx0tAWceqIMlOEeDpzHSQ0AAAAAzCzRdBwJRA4VAAAAAgAAAA=="))}, "EV::IO"),
    io_socket_peername => pack("H*","0200dd90c0a8010e0000000000000000"),
    io_socket_timeout => "0.001",
  };
  ($a, "Alarm: fired event");
} at /Slim/Utils/Alarm.pm line 1991.
[22-12-01 09:12:03.2203] Slim::Utils::Alarm::_alarmEnd (1992) Unknown source: CLI
[22-12-01 09:12:03.2205] Slim::Utils::Alarm::_alarmEnd (2002) Stopping alarm
[22-12-01 09:12:03.2211] Slim::Utils::Alarm::popAlarmScreensaver (1866) Attempting to pop alarm screensaver.  Current mode: INPUT.List
[22-12-01 09:12:04.2183] Slim::Utils::Alarm::__ANON__ (896) Restoring pre-alarm volume level: 32
[22-12-01 09:12:04.2198] Slim::Utils::Alarm::__ANON__ (901) Restoring pre-alarm shuffle mode: 0
[22-12-01 09:12:04.2206] Slim::Utils::Alarm::__ANON__ (905) Restoring pre-alarm power state: on

The ending of my alarm log looks very similar to yours. In my case though although the log says the alarm has been stopped the alarm screen did not close on the player.
Do we know what
"Attempting to pop alarm screensaver" means?

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

So far all my alarm testing has been on a Radio where pausing an alarm remotely doesn't cancel the alarm correctly and stopping an alarm remotely sometimes cancels the alarm correctly.
So I tried setting alarms on a Touch and so far both pausing and stopping an alarm remotely has worked correctly every time. So what is the difference?

Sent from my Pixel 3a using Tapatalk

[gordonb3]

The ending of my alarm log looks very similar to yours. In my case though although the log says the alarm has been stopped the alarm screen did not close on the player.
Do we know what
"Attempting to pop alarm screensaver" means?

Push and Pop are stack related terms. Push means to save the current state and replace it with something new, Pop is the reverse and restores that earlier state.

[mherger]

Alarm not working with 8.3?

> Just to add another usage case, my morning alarm is set up for a stereo
> pair of Google Nest Minis using Philippe's Castbridge plugin. The alarm
> had become unreliable in recent months but has not failed since applying
> the most recent updates to Material Skin and LMS. Following is a debug
> log of this morning's successful alarm trigger and subsequent successful
> pause/stop, which was achieved by saying "Google, stop the music". Note
> that the source for the pause request is "CLI".

Ok, ok. There's a use case for other control points :-). Nice one!

[slartibartfast]

@mherger Any thoughts on why the Radio and the Touch behave differently when the alarm is paused or stopped from a remote source? I wonder if the last official firmware of the Touch contained any changes related to this which were not in the Radio firmware.

Sent from my Pixel 3a using Tapatalk