Home of the Squeezebox™ & Transporter® network music players.

View Poll Results: On what player types does the alarm fail for you?

Voters
21. You may not vote on this poll
  • Squeezebox Radio (official firmware 7.x)

    3 14.29%
  • Squeezebox Radio (community firmware 8.x)

    13 61.90%
  • Squeezebox Touch (official firmware 7.x)

    0 0%
  • Squeezebox Touch (community firmware 8.x)

    0 0%
  • SB Classic/Boom/Receiver/Transporter

    3 14.29%
  • Other (eg. Raspberry Pi based)

    4 19.05%
Multiple Choice Poll.
Page 24 of 24 FirstFirst ... 14222324
Results 231 to 240 of 240
  1. #231
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Quote Originally Posted by slartibartfast View Post
    Seriously . 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.
    Quote Originally Posted by slartibartfast View Post
    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
    Last edited by KeBul; 2022-12-02 at 12:53.

  2. #232
    Senior Member
    Join Date
    Mar 2017
    Posts
    3,735
    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?
    Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

  3. #233
    Senior Member
    Join Date
    Jan 2010
    Location
    Hertfordshire
    Posts
    9,667
    Quote Originally Posted by KeBul View Post
    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

  4. #234
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Quote Originally Posted by cpd73 View Post
    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
    Last edited by KeBul; 2022-12-02 at 18:04.

  5. #235
    Senior Member
    Join Date
    Mar 2017
    Posts
    3,735
    Quote Originally Posted by KeBul View Post
    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.

    Quote Originally Posted by KeBul View Post
    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.

    Quote Originally Posted by KeBul View Post
    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.
    Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

  6. #236
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Quote Originally Posted by cpd73 View Post
    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 . )

    Quote Originally Posted by cpd73 View Post
    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.

    Quote Originally Posted by cpd73 View Post
    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

  7. #237
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,776

    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 :-).

  8. #238
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    488
    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.
    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?
    Sam

  9. #239
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,776

    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?

  10. #240
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Well somewhat disappointing news today...

    This morning my 7am Back Bedroom alarm failed to trigger...

    [22-12-04 07:00:37.4903] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause

    _source => "/5cf52aae/slim/request|100||5cf52aae|SqueezePlay-baby/8.0.1-r16855 (armv5tejl)",

    So this was a "request" from the player itself (I know that because it's the only player with firmware 16855), even though the player was not touched (I slept through till 9:30), but possibly relevant the last thing done on the player was to turn it off by it's power button and the player is configured to pause on power off.

    There was a nice block of "ignoring self-created request" and "Ignoring unwanted notifications" - so handling of those seemed to be working fine

    [22-12-04 07:00:00.0625] Slim::Utils::Alarm::_alarmEnd (1982) Ignoring self-created request
    [22-12-04 07:00:00.0811] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist stop
    [22-12-04 07:00:10.2100] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist pause
    [22-12-04 07:00:37.2776] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: mode stop
    [22-12-04 07:00:37.2836] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist stop

    So unlike my testing scenarios this wasn't a failure with a 'playerprefs' source directly involved, the system had not been restarted after Friday's testing, so I guess still had all the elements for trigger and failure embedded in there somewhere.

    I've tried to put MaterialSkin vTest back on, but fails to load with "Can't locate Plugins/MaterialSkin/Plugin.pm in @INC", I think I'm doing the same as before for a manual plugin zip install, but I must be missing something because it's not having it.

    Kev

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •