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 17 of 25 FirstFirst ... 71516171819 ... LastLast
Results 161 to 170 of 247
  1. #161
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    499
    This is the most interesting forum thread I've followed in a long time. It reads like a mystery novel. Each day I come here to read the next chapter. Like Michael, though, my alarms have been working without fail for weeks now after a period where they were failing fairly often. I'm running with the new source debug change though and will post if I see anything unusual. Btw, I also am a Material Skin user and had just begun using it regularly when my alarm failures started showing up a few months ago.
    Sam

  2. #162
    Senior Member
    Join Date
    Mar 2017
    Posts
    3,746

    Material test version

    Can someone please try using the attached Material version? I've remove the playerprefs "unsubscribe"

    lms-material-test.zip
    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. #163
    Senior Member
    Join Date
    Dec 2020
    Posts
    325
    Do note that the SB devices themselves appear to use cometd as well as indicated by this log snippet:
    Code:
    [22-11-22 17:01:44.4157] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause
    [22-11-22 17:01:44.4178] Slim::Utils::Alarm::_alarmEnd (1980) stop requested by '/338b2cbb/slim/request|649||338b2cbb|SqueezePlay-baby/8.0.1-r16907 (armv5tejl)'
    So it isn't strictly necessary to be using Material, it may also be e.g. SB controller or (uncommon but possible) a player with a graphical interface that is used to control a second player. Regarding the comment about needing to remove the skin, as far as I'm aware the skin itself doesn't do anything on its own. It merely allows a browser to subscribe to notifications prompting it to perform certain actions like displaying the active song name, volume level, or as turns out to be happening here resync preferences. The whole point here is that you must have an active client and it must have subscribed to notifications concerning the player that is to play the alarm. If there is no active client then there will be no response and subsequently no request to resync preferences.

    BTW the "fool proof" method I described did for some reason not work out as fool proof for me today. I had several occurrences where no cometd client intervened with the alarm and so it does seem pretty random. I'm quite certain however that the fix posted above works, ugly as it is.
    Last edited by gordonb3; 2022-11-23 at 10:39.

  4. #164
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Quote Originally Posted by cpd73 View Post
    Can someone please try using the attached Material version? I've remove the playerprefs "unsubscribe"

    lms-material-test.zip
    Thanks Craig I've downloaded and will install it soon, just running a test with Material removed from the system at the moment, want to give that a day or so and then wanted to test with current released Material but with a non MacOS/IOS/Safari device/browser.

    Quote Originally Posted by gordonb3 View Post
    Do note that the SB devices themselves appear to use cometd as well as indicated by this log snippet:
    Code:
    [22-11-22 17:01:44.4157] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: pause
    [22-11-22 17:01:44.4178] Slim::Utils::Alarm::_alarmEnd (1980) stop requested by '/338b2cbb/slim/request|649||338b2cbb|SqueezePlay-baby/8.0.1-r16907 (armv5tejl)'
    So it isn't strictly necessary to be using Material, it may also be e.g. SB controller or (uncommon but possible) a player with a graphical interface that is used to control a second player. Regarding the comment about needing to remove the skin, as far as I'm aware the skin itself doesn't do anything on its own. It merely allows a browser to subscribe to notifications prompting it to perform certain actions like displaying the active song name, volume level, or as turns out to be happening here resync preferences. The whole point here is that you must have an active client and it must have subscribed to notifications concerning the player that is to play the alarm. If there is no active client then there will be no response and subsequently no request to resync preferences.
    But are these cometd "playerprefs"?.. I can get various sources reported rather than "ALARM", such as the player itself - pressing pause,
    If I try and emulate what I was doing in Material By taking control of the SB Radio under test from a Touch and then release control again I do not see an unknown source with "playerprefs" reported by the alarm.
    If I leave the Touch controlling the SB Radio and turn off the Radio after the alarm has succeeded then I see a power request with source reported as "Squeezeplay-fab4"

    All the failures I have seen have been with a Stop request and a source including "Playerprefs" and Safari

    Quote Originally Posted by gordonb3 View Post
    BTW the "fool proof" method I described did for some reason not work out as fool proof for me today. I had several occurrences where no cometd client intervened with the alarm and so it does seem pretty random. I'm quite certain however that the fix posted above works, ugly as it is.
    When you say occurrences - do you mean actual alarm failures but no cometd shown as the source...

    Cheers

    Kev

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

    Alarm not working with 8.3?

    > Shows the Material client shutting down the alarm 99% of the time in all
    > 8.x versions.

    Does it really _fail_ the alarm, or just log that one statement? Because
    we still believe this was a 8.3 only issue...

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

    Alarm not working with 8.3?

    > Do note that the SB devices themselves appear to use cometd as well as
    > indicated by this log snippet:


    But that's ok, isn't it? If you hit power off on the device then the
    alarm is expected to stop.

    > So it isn't strictly necessary to be using Material, it may also be e.g.


    The difference here is that the above is an interaction between the user
    and the system, whereas in the case of Material it's an automated
    reaction to some state change (a subscription).

  7. #167
    Senior Member
    Join Date
    Dec 2020
    Posts
    325
    Quote Originally Posted by KeBul View Post
    But are these cometd "playerprefs"?.. I can get various sources reported rather than "ALARM", such as the player itself - pressing pause,
    If I try and emulate what I was doing in Material By taking control of the SB Radio under test from a Touch and then release control again I do not see an unknown source with "playerprefs" reported by the alarm.
    If I leave the Touch controlling the SB Radio and turn off the Radio after the alarm has succeeded then I see a power request with source reported as "Squeezeplay-fab4"

    All the failures I have seen have been with a Stop request and a source including "Playerprefs" and Safari
    I don't think it is specific to cometd. The ignore routine inside _alarmEnd is already there so there is a known bug (although the person that knows may have left Logitech a long time ago) with the state change that causes a response that shuts down the alarm. The only thing different here is that we are now seeing an external source accessing this bug and the ignore routine failing to block that auto created request.

    When you say occurrences - do you mean actual alarm failures but no cometd shown as the source...
    No, my aim was to see a failed alarm so what I meant here is that the alarm did in fact sound and the log showed that the attempt to stop it was successfully blocked by the ignore routine.

  8. #168
    Senior Member
    Join Date
    Dec 2020
    Posts
    325
    Quote Originally Posted by mherger View Post
    > Shows the Material client shutting down the alarm 99% of the time in all
    > 8.x versions.

    Does it really _fail_ the alarm, or just log that one statement? Because
    we still believe this was a 8.3 only issue...
    Quote Originally Posted by mherger View Post
    > Do note that the SB devices themselves appear to use cometd as well as
    > indicated by this log snippet:


    But that's ok, isn't it? If you hit power off on the device then the
    alarm is expected to stop.

    > So it isn't strictly necessary to be using Material, it may also be e.g.


    The difference here is that the above is an interaction between the user
    and the system, whereas in the case of Material it's an automated
    reaction to some state change (a subscription).
    See my reaction to Kev. In my view this is simply unfortunate timing of parallel developments and yes it does require a fairly specific environment so the majority of users will not be affected by the bug.

    As for the randomness like I mentioned earlier there does appear to be a time factor involved as well. Can't really pinpoint it, but yesterday I couldn't make the alarm fail until I subscribed to a third player in my Material session. The logs are also somewhat puzzling as for every alarm that is being triggered there is an _alarmEnd response but there is always only one, i.e. if the Material client pops up issuing this request 'ALARM' which is expected to show up there doesn't. I mentioned earlier that I suspected this to be a logging issue but in hindsight I think LMS may be blocking multiple prefsync requests issued simultaneously and only serving the one that is first in queue. This makes it plausible that you could never replicate this if you run LMS on a workstation class machine where LMS is likely to win that election every time.

  9. #169
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463

    Todays testing update, No MaterialSkin and MaterialSkin-Test for Craig

    I wasn't expecting to do much on this today with other plans afoot, but my wife tested positive for Covid-19 this morning so we are isolating at home.

    I decided to short cut my testing plans as well... I'd run almost a day without Material installed, 28 alarms triggered successfully during that period and no failures seen and as Craig had taken the time to produce a MaterialSkin-Test build without the "playprefs unsubscribe" I decided to drop that in and test that.

    So far it's looking good, MaterialSkin vTest was installed just after 3pm and the first alarm scheduled for 3:15, 14 alarm triggers later still no failures and I've been adhoc testing all sorts of scenarios around use of Material, including many attempts at how I managed to get it to fail previously.

    Alarms are due to start again soon, I've gradually increased the alarms configured - I'm amazed, it's up to 33 now!! I'll carry on testing and then continue tomorrow - there's no guarantee because the failure is so unpredictable, but so far, including the run without Material installed, this must be the most alarms in sequence without a failure I've had since I started testing.

    I'll report back again tomorrow.

    Kev
    Last edited by KeBul; 2022-11-26 at 02:21.

  10. #170
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    463
    Another day of alarms... no changes to the set up, just alarms set every 15 minutes and some use of MaterialSkin.

    41 alarms, no failures, so looking like Craig's proposed tweak in MaterialSkin has helped the situation.

    I don't think I can do any more with this current setup, depending how I feel tomorrow I may go back to the released version of Material and see if I can break it again and then try with a different OS/Browser.

    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
  •