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

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

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

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

    12 60.00%
  • Squeezebox Touch (official firmware 7.x)

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

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

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

    4 20.00%
Multiple Choice Poll.
Page 19 of 19 FirstFirst ... 9171819
Results 181 to 189 of 189
  1. #181
    Senior Member KeBul's Avatar
    Join Date
    Sep 2009
    Location
    London
    Posts
    450
    Quote Originally Posted by gordonb3 View Post
    If you could I would appreciate you verifying the patch for the LMS side I posted earlier (with the 'bad' MaterialSkin). Obviously it is good when the current issue gets solved from whatever side but I think the objective should be to stop this forever rather than rely on Craig fixing it all.
    I tested this last night and it seemed to work...

    Code:
    # Don't respond to requests that we created ourselves
    	my $source = $request->source;
    	if ($source && (($source eq 'ALARM') || ($source eq 'PLUGIN_RANDOMPLAY') || (index($source,'playerprefs') != -1))) {
    		warn Data::Dump::dump($request, 'Alarm: ignored event');
    		main::DEBUGLOG && $isDebug && $log->debug('Ignoring self-created request');
    		return;
    	}
    	elsif ($source) {
    		warn Data::Dump::dump($request, 'Alarm: fired event');
    		$log->error("Unknown source: $source");
    	}
    Here's my test actions/results log:

    21:25 - Alarm OK - timeout to end, log file shows source=ALARM
    21:40 - Alarm OK - timeout to end, log file shows source=ALARM
    Opened Material MacOS/Safari, swapped players from BB to SR2 and then to Lounge - left monitoring Lounge
    21:55 - Alarm OK - timeout to end, log file shows source=blahblah'playerprefs’
    22:10 - Alarm OK - Turned off Material player dropdown, log file shows source=ALARM
    22:30 - Alarm OK - timeout to end, log file shows source=blahblah’playerprefs’
    22:40 - Alarm OK - timeout to end, log file shows source=ALARM, changed to SR2 and then back to Lounge in Material
    22:50 - Alarm OK - timeout to end, log file shows source=blahblah’playerprefs’, changed to SR2 and then back to Lounge in Material
    23:00 - Alarm OK - timeout to end, log file shows source=blahblah’playerprefs’

    Here's a debug extract from 21:55 alarm which showed a source of 'playerprefs' but the Alarm still worked:

    [22-11-26 21:55:00.0011] Slim::Utils::Alarm::sound (516) Alarm triggered for Spare Radio 2
    [22-11-26 21:55:00.0020] Slim::Utils::Alarm::sound (560) Sounding alarm
    [22-11-26 21:55:00.0045] Slim::Utils::Alarm::sound (589) Current Power State: Off
    [22-11-26 21:55:00.0091] Slim::Utils::Alarm:ushAlarmScreensaver (1839) Attempting to push into alarm screensaver: . Current mode: INPUT.List
    [22-11-26 21:55:00.0100] Slim::Utils::Alarm::sound (609) Current vol: 18 Alarm vol: 18
    [22-11-26 21:55:00.0109] Slim::Utils::Alarm::sound (622) Alarm playlist shufflemode: 0
    [22-11-26 21:55:00.0124] Slim::Utils::Alarm::sound (628) Alarm playlist url: sounds://_LIVE_bbc_radio_two
    [22-11-26 21:55:00.0317] Slim::Utils::Alarm::_setAlarmSubscription (1204) Adding alarm subscription
    [22-11-26 21:55:00.0329] Slim::Utils::Alarm::sound (697) Scheduling time out in 300 seconds
    [22-11-26 21:55:00.0338] Slim::Utils::Alarm::_startStopTimeCheck (1880) 0 scheduled alarm(s)
    [22-11-26 21:55:00.0341] Slim::Utils::Alarm::_startStopTimeCheck (1889) Stopping time checker task
    [22-11-26 21:55:00.0348] Slim::Utils::Alarm::scheduleNext (1391) Asked to schedule next alarm for Spare Radio 2
    [22-11-26 21:55:00.0353] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 14:0:0 27/11/2022
    [22-11-26 21:55:00.0356] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 21:55:0 26/11/2022
    ~KeBul - removed lots of findNextTime entries~
    [22-11-26 21:55:00.0680] Slim::Utils::Alarm::findNextTime (461) Potential next time found: 16:15:0 27/11/2022
    [22-11-26 21:55:00.0684] Slim::Utils::Alarm::findNextTime (466) Last alarm due: 21:55:0 26/11/2022
    [22-11-26 21:55:00.0688] Slim::Utils::Alarm::scheduleNext (1424) Next alarm is at 22:10:0 26/11/2022
    [22-11-26 21:55:00.0692] Slim::Utils::Alarm::scheduleNext (1435) Scheduling alarm
    [22-11-26 21:55:00.0696] Slim::Utils::Alarm::_startStopTimeCheck (1880) 1 scheduled alarm(s)
    [22-11-26 21:55:00.0700] Slim::Utils::Alarm::_startStopTimeCheck (1884) Starting time checker task
    [22-11-26 21:55:00.0785] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: stop
    [22-11-26 21:55:00.0805] Slim::Utils::Misc::msg (1325) Warning: [21:55:00.0800] (
    bless({
    _cb_args => undef,
    _cb_enable => 1,
    _cb_func => undef,
    _clientid => "00:04:20:26:1d:b9",
    _func => sub { "???" },
    _isQuery => 0,
    _langoverride => undef,
    _needClient => 1,
    _params => {},
    _request => ["stop"],
    _requeststr => "stop",
    _results => {},
    _source => "/91843e22/slim/playerprefs/00:04:20:26:1d:b9|17||91843e22|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15",
    _status => 10,
    _useixhash => 0,
    }, "Slim::Control::Request"),
    "Alarm: ignored event",
    ) at /usr/local/slimserver/Slim/Utils/Alarm.pm line 1981.
    [22-11-26 21:55:00.0810] Slim::Utils::Alarm::_alarmEnd (1982) Ignoring self-created request
    [22-11-26 21:55:00.0846] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd called with request: power
    [22-11-26 21:55:00.0866] Slim::Utils::Misc::msg (1325) Warning: [21:55:00.0861] (
    bless({
    _cb_args => undef,
    _cb_enable => 1,
    _cb_func => undef,
    _clientid => "00:04:20:26:1d:b9",
    _func => sub { "???" },
    _isQuery => 0,
    _langoverride => undef,
    _needClient => 1,
    _params => { _newvalue => 1, _noplay => undef },
    _request => ["power"],
    _requeststr => "power",
    _results => {},
    _source => "/91843e22/slim/playerprefs/00:04:20:26:1d:b9|17||91843e22|Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15",
    _status => 10,
    _useixhash => 0,
    }, "Slim::Control::Request"),
    "Alarm: ignored event",
    ) at /usr/local/slimserver/Slim/Utils/Alarm.pm line 1981.
    [22-11-26 21:55:00.0870] Slim::Utils::Alarm::_alarmEnd (1982) Ignoring self-created request
    [22-11-26 21:55:00.1666] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring unwanted notification: playlist stop
    [22-11-26 22:00:00.0341] Slim::Utils::Alarm::_timeout (1162) Alarm b609635f ending automatically due to timeout
    [22-11-26 22:00:00.0429] Slim::Utils::Alarm:opAlarmScreensaver (1866) Attempting to pop alarm screensaver. Current mode: INPUT.List
    [22-11-26 22:00:01.0434] Slim::Utils::Alarm::__ANON__ (896) Restoring pre-alarm volume level: 18
    [22-11-26 22:00:01.0450] Slim::Utils::Alarm::__ANON__ (901) Restoring pre-alarm shuffle mode: 0
    [22-11-26 22:00:01.0467] Slim::Utils::Alarm::__ANON__ (905) Restoring pre-alarm power state: off

    Cheers

    Kev
    Last edited by KeBul; Yesterday at 09:40.

  2. #182
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    484
    Quote Originally Posted by KeBul View Post
    Testing this change today, I'm still getting alarm failures, first a sanity check...
    I suspect a typo in Michael's second regex, checking for a MAC address in the source but I don't see it offhand.
    Last edited by SamY; Yesterday at 09:34.
    Sam

  3. #183
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    484
    Quote Originally Posted by SamY View Post
    I suspect a typo in Michael's second regex, checking for a MAC address in the source but I don't see it offhand.
    At the risk of exposing my limited knowledge of the intricacies of regular expressions, I believe the problem could be the trailing 'i' after the pattern in the last regex. I would replace:

    Code:
    m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]:){5}[0-9a-f]|i
    with:

    Code:
    m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]:){5}[0-9a-f]|
    i.e. No trailing 'i'
    Sam

  4. #184
    Senior Member
    Join Date
    Apr 2005
    Location
    UK/London
    Posts
    6,264
    The trailing i is to indicate that the text matching should be case-insensitive.
    Paul Webster
    Author of "Now Playing" plugins covering Radio France (FIP etc), PlanetRadio (Bauer - Kiss, Absolute, Scala, JazzFM etc), KCRW, ABC Australia and CBC/Radio-Canada
    and, via the extra "Radio Now Playing" plugin lots more - see https://forums.slimdevices.com/showt...Playing-plugin

  5. #185
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    484
    Quote Originally Posted by Paul Webster View Post
    The trailing i is to indicate that the text matching should be case-insensitive.
    I stand exposed...
    Sam

  6. #186
    Senior Member
    Join Date
    Sep 2018
    Location
    Hamburg
    Posts
    181
    Really interesting thread and thanks for tirelessly chasing the bug. This morning I had it again - faulty/non-triggered alarm with my 8.3.1 setup and the whole family overslept - the interesting thing about it, I hadn't touched the setup for the past few weeks and I hadn't adjusted the alarm either and it was reliable over this weeks. In my view, material was not really involved and the alarm was always acknowledged over the radios - anyway, I'm really happy that the issue has been recognized and will be fixed soon.

    Best regards and thank you so much!

    LMS: 8.3.1 - 1667914563
    on RPi4/ Raspbian Buster 10
    points to MusicLibrary on QNAP TS212 (NFS)

    1x Duet - Cntrl-FW: 8.0.1-r16907/ Receiver-FW: 77
    2x SB Radio - FW: 8.0.1-r16907
    1x Squeezebox Boom - FW 57
    1x Transporter - FW: 87
    RPi 2B - pCP 8.0.1/ SqueezeLite v1.9.9-1391-pCP
    Softsqueeze 3.9.2 on Win 10 / Squeezeplay 8.0.1r1343 on Win 10
    Squeeze Player 1.3.21 on S22/Android 13.0.0

    Controller:
    Android Phone - Squeezer 2.3.0/ Material Skin 3.0.1

  7. #187
    Senior Member
    Join Date
    Oct 2014
    Location
    Pittsburgh PA
    Posts
    484
    Quote Originally Posted by SamY View Post
    I stand exposed...
    Okay. I've got it this time. No, REALLY!!!
    (I verified it with a regex testing utility.)
    The problem is missing quantifiers after the components of the MAC address so the solution is to change:

    Code:
    m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]:){5}[0-9a-f]|
    To:

    Code:
    m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]+:){5}[0-9a-f]+|
    Or, to be more strict:

    Code:
    m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]{2}:){5}[0-9a-f]{2}|
    Hopefully this post will redeem my technical credibility to at least a minor extent. In any case, the change should allow Michael's solution to function as intended.
    Sam

  8. #188
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,775

    Alarm not working with 8.3?

    > Okay. I've got it this time. No, REALLY!!!
    > (I verified it with a regex testing utility.)
    > The problem is missing quantifiers after the components of the MAC


    You're correct!

    > Hopefully this post will redeem my technical credibility to at least a
    > minor extent. In any case, the change should allow Michael's solution to
    > function as intended.


    Thanks! You got my blessing :-D

  9. #189
    Senior Member
    Join Date
    Dec 2020
    Posts
    321
    Quote Originally Posted by mherger View Post
    Rather than just blocking player-refs notifications we should probably just ignore any player specific notification:

    Code:
    diff --git a/Slim/Utils/Alarm.pm b/Slim/Utils/Alarm.pm
    index e6acade08..abf4be8a6 100644
    --- a/Slim/Utils/Alarm.pm
    +++ b/Slim/Utils/Alarm.pm
    @@ -1982,6 +1982,11 @@ sub _alarmEnd {
                    main::DEBUGLOG && $isDebug && $log->debug('Ignoring self-created request');
                    return;
            }
    +       elsif ($source && $source !~ m|^/[a-z0-9]+/slim/request| && $source =~ m|^/[a-z0-9]+/slim/\w+/(?:[0-9a-f]:){5}[0-9a-f]|i) {
    +               warn Data::Dump::dump($request, 'Alarm: ignored event');
    +               main::DEBUGLOG && $isDebug && $log->debug('Ignoring notification to subscriber');
    +               return;
    +       }
            elsif ($source) {
                    warn Data::Dump::dump($request, 'Alarm: fired event');
                    $log->error("Unknown source: $source");
    Would anybody be able to apply this and test? I think that (most) interactive actions taken by a user would be `/abc213/slim/request`, whereas notification come with a MAC address in the source element. As notifications already are in response to some action we should ignore them.
    I actually think that the MAC address is included in the source string when the associated session is controlling a different device, i.e. other than itself. This regex might thus block legit actions to stop the alarm from e.g. Controller.

    Also not completely unimportant, `index()` is more CPU friendly than regex, even if the latter is applied with fixed strings.

Posting Permissions

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