Alarm not working with 8.3?

[KeBul]

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?

@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.

I can reproduce the pause and stop not closing down an alarm completely problem on my SB Touch

Kev

[slartibartfast]

I can reproduce the pause and stop not closing down an alarm completely problem on my SB Touch

Kev

Seriously [emoji1787]. How consistent were your results? I tried four times in a row and each time the alarm screen closed down. Even with pause and that never works on the Radio.

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

I can reproduce the pause and stop not closing down an alarm completely problem on my SB Touch

Kev

I just tried seven alarms on the Touch and every time the alarm was cancelled correctly with three "Stops" and four "Pauses".

Sent from my Pixel 3a using Tapatalk

[mherger]

Alarm not working with 8.3?

> @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

I don't know... some of the very last changes were indeed related to the
Alarm. But I've lost track of what is in which firmware version.

https://github.com/Logitech/squeezeplay/commits/public/7.8

[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

I don't know... some of the very last changes were indeed related to the
Alarm. But I've lost track of what is in which firmware version.

https://github.com/Logitech/squeezep...its/public/7.8

I suppose this could be the culprit

https://github.com/Logitech/squeezeplay/commit/d5d4e0590a1b962395f00535453276b3baa429b4

Sent from my Pixel 3a using Tapatalk

[slartibartfast]

I suppose this could be the culprit

https://github.com/Logitech/squeezeplay/commit/d5d4e0590a1b962395f00535453276b3baa429b4

Sent from my Pixel 3a using Tapatalk

Although that code is in Squeezeplay for Windows and that also has the issue where the alarm screen does not close down when stopped or paused remotely.

Sent from my Pixel 3a using Tapatalk

[KeBul]

Seriously [emoji1787]. How consistent were your results? I tried four times in a row and each time the alarm screen closed down. Even with pause and that never works on the Radio.

I just tried seven alarms on the Touch and every time the alarm was cancelled correctly with three "Stops" and four "Pauses".

Yep seriously, worked for the first couple of alarms but then started failing each time. Just set up another test - failed 3 out of 4.

Not as reliable to fail as pause on a Radio, but definitely still happening.

Kev

[cpd73]

I'm going to release an update to Material soon. Should I remove the unsubscribe? Will that work-around the issue? Or should I leave Material as is and wait for the fix in LMS itself?

[slartibartfast]

Yep seriously, worked for the first couple of alarms but then started failing each time. Just set up another test - failed 3 out of 4.

Not as reliable to fail as pause on a Radio, but definitely still happening.

Kev

I wonder why we don't see the same behaviour...

Sent from my Pixel 3a using Tapatalk

[KeBul]

I'm going to release an update to Material soon. Should I remove the unsubscribe? Will that work-around the issue? Or should I leave Material as is and wait for the fix in LMS itself?

Hi Craig,

Checking back on your posts you say you introduced this method of unsubscribe in July 2022 - what was the reason for that introduction?
What would be the potential impact of removing the unsubscribe, apart from maybe a fix for the recent alarm problem(s)?

Michael doesn't seem to believe Material is to blame - however, I have tested extensively several times without Material installed and not had any alarm failures, but there's a caveat to that - the only way I can "reliably" induce failures during testing is by playing around and changing between players in Material - with no Material installed I can't do that.
Having said that, the testing I did with your MaterialSkin vTest, which had the unsubscribe removed, was quite extensive with lots of changing between players but no alarm failures were seen.

Michaels ignore 'playerprefs' fix in Alarm.pm resolves or at least drastically improves the problem where an alarm fails to trigger, but seems to have made another issue worse - "using a remote device to pause or stop an alarm". Although I agree with him that this is considerably less of an issue than an alarm failing to trigger, so we are in a better place at the moment.
The testing I've done for this issue also seems to indicate that without Material installed pause works every time, i.e. the alarm is successfully shutdown, once Material is installed the issue for me becomes prevalent, pause regularly fails to completely shutdown an alarm.
I haven't tested MaterialSkin vTest against this issue, if you would like me to do so let me know, but from what I'm seeing in the logs I would be surprised if removing the unsubscribe didn't also help with this.

In short, albeit from a pure testing evidential standpoint rather than in-depth knowledge of Material and LMS and the protocols/code/interactions between them etc.. I think that Material currently is a trigger for whatever is going wrong within the player and alarm handling, from the testing with MaterialSkin vTest, it looks like removing the unsubscribe either stops that trigger or greatly reduces it.

I think it's also worth noting that Michael started this thread and first reported he was having strange alarm issues early Aug, possibly not that long after your July unsubscribe change. ~Insert smoking gun emoji here~

Kev

[cpd73]

Checking back on your posts you say you introduced this method of unsubscribe in July 22 - what was the reason for that introduction?

Mainly to cleanup - I believe if you subscribe to a message you should unsubscribe when you no longer want to be informed. I think it was missing before due to a simple oversight.

What would be the potential impact of removing the unsubscribe (apart from maybe a fix for the alarm problem)?

Probably none, as Material has worked for years before this change.

Michael doesn't seem to believe Material is to blame - however, I have tested several times without Material installed and not had any alarm failures, but there's a caveat to that - the only way I can "reliably" induce failures during testing is by playing around and changing between players in Material - with no Material installed I can't do that.
Having said that, the testing I did with your MaterialSkin vTest, which had the unsubscribe removed, was quite extensive with lots of changing between players but no alarm failures were seen.

I don't 100% believe Material is wrong, just that its behavior triggers this issue in LMS.

[KeBul]

Mainly to cleanup - I believe if you subscribe to a message you should unsubscribe when you no longer want to be informed. I think it was missing before due to a simple oversight.

Yeah sure, makes sense - wish I had a better understanding of all this (and a better capability to understand all this . )

Probably none, as Material has worked for years before this change.

So although not as tidy as you would like, a very low risk to revert that change.

I don't 100% believe Material is wrong, just that its behaviour triggers this issue in LMS.

Same place I've got to on this one.
There's been some good work done investigating though by yourself, Michael and gordonb3, but seems to be quite a few unanswered questions floating around, like yours on correct method to unsubscribe and gordon's on why the alarms always seem to start with an ignored self request "Stop"

Must say as well, while conversing with you - amazing job you've done on Material it's a lovely modern interface for LMS

Kev

[mherger]

Alarm not working with 8.3?

> Michael doesn't seem to believe Material is to blame - however, I have
> tested several times without Material installed and not had any alarm
> failures, but there's a caveat to that - the only way I can "reliably"
> induce failures during testing is by playing around and changing between
> players in Material - with no Material installed I can't do that.

Yes, I believe Material is only triggering an issue in LMS. But to
ignore _notifications_ in the alarm code seems the right thing to me.
They usually echo an action taken elsewhere. And we should only act on
actual input, not on notification (unless we subscribe to them, of course).

Why that introduces another issue, I have no clue. I remember Felix, and
old Squeezebox buddie of the time, who had to work on Alarm code at a
later stage, once mentioned he would never use it. The Alarm code
combined (LMS & firmware) was just too complicated, dealing with too
many possible failures...

> I think it's also worth noting that Michael started this thread and
> first reported he was having strange alarm issues early Aug, about 2
> weeks after your unsubscribe change. ~Insert smoking gun emoji here~

It was the return to school time - we hadn't used the alarm for several
weeks :-).

[SamY]

I apologize if this post is off-topic but there is a chance that it might be related in a tangential way. About 3 months ago, a user of the Denon AVR plugin that I co-maintain reported strange behavior and provided a debug log illustrating it. It appeared that the problem was caused by the notification callback in the plugin being called for events from players other than those for which the plugin had registered (subscribed) the callback --- a condition that the code was completely unprepared to handle. Upon further research, it was discovered that the players in questions were ones that had been synched with a player that WAS registered for the events. I was able to easily recreate the situation and coded a fix (workaround?) that was fairly simple but added some cpu overhead --- add and maintain an array of player id's that are currently registered for the notifications and ignore any event callbacks from unregistered players. However, it seemed strange to me at the time that a problem with as common a use case as this should suddenly appear in a plugin that had been in fairly widespread use for over 10 years. I also had doubts about whether or not the behavior was intentional/correct after looking at the LMS doc pages. So here's my question:

When registering a notification callback for a particular player ($client), e.g.

Slim::Control::Request::subscribe( \&commandCallback, [['power', 'play', 'playlist', 'pause', 'mixer']], $client);

is it expected/intended that the callback should also be invoked for other players that are synched with that player?

[mherger]

Alarm not working with 8.3?

> When registering a notification callback for a particular player
> ($client), e.g.
> Code:
> --------------------
> Slim::Control::Request::subscribe( \&commandCallback, [['power', 'play', 'playlist', 'pause', 'mixer']], $client);
> --------------------
> is it expected/intended that the callback should also be invoked for
> other players that are synched with that player?

I don't think it is. But I'm not too familiar with that code. If you
check the client in your callback, would it be called for _all_ synched
players or only ever one, but not always the one to be expected?