------------------------------------------------------------------------ A poll associated with this post was created, to vote and see the results, please visit http://forums.slimdevices.com/showthread.php?t=116649 ------------------------------------------------------------------------ Question: On what player types does the alarm fail for you? - Squeezebox Radio (official firmware 7.x) - Squeezebox Radio (community firmware 8.x) - Squeezebox Touch (official firmware 7.x) - Squeezebox Touch (community firmware 8.x) - SB Classic/Boom/Receiver/Transporter - Other (eg. Raspberry Pi based) ------------------------------------------------------------------------
mherger wrote: > didjean - thank you very much for this posting and the log file! I think > > we got a lead: > > invalid: > > > [22-11-17 20:45:01.7436] Slim::Utils::Alarm::_alarmEnd (1970) > _alarmEnd > > called with request: stop > > [22-11-17 20:45:01.7442] Slim::Utils::Alarm::_alarmEnd (1992) > Stopping > > alarm > > vs. correct: > > > [22-11-17 21:03:02.2268] Slim::Utils::Alarm::_alarmEnd (1970) > _alarmEnd > > called with request: stop > > [22-11-17 21:03:02.2271] Slim::Utils::Alarm::_alarmEnd (1981) > Ignoring > > self-created request > > > If we compare both logs - last 7 lines are different. > > Yep! There is code in Alarm (and LMS in general) to define the source of > > a request. Alarm would use this to not act on its own commands, but on > commands coming from other parts of the system. In the failing case this > > flag seems to be missing or modified. Alarm doesn't recognize the "stop" > > command as coming from itself. > > It remains to be figured out what that would happen _sometimes_. And > it's my understanding that it would start to fail at some point, and not > > recover once in that mode. I'd pretty much given up on 8.3 because of this issue, so nice to see some progress on this and very much appreciate the efforts of all - although I pointed out the failures acted on the this in post #12 of this thread :p ... KeBul wrote: > > Comparing the two, after scheduling the next alarm and starting the time > checker task (1884) on the alarm that worked the next two (spurious??) > alarmEnd (1970) commands are ignored (1981's), with a further ignore of > a playlist stop (1966) > > [22-08-10 10:30:00.0564] Slim::Utils::Alarm::_startStopTimeCheck > (1884) Starting time checker task > [22-08-10 10:30:00.0649] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd > called with request: stop > [22-08-10 10:30:00.0654] Slim::Utils::Alarm::_alarmEnd (1981) Ignoring > self-created request > [22-08-10 10:30:00.0686] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd > called with request: power > [22-08-10 10:30:00.0691] Slim::Utils::Alarm::_alarmEnd (1981) Ignoring > self-created request > [22-08-10 10:30:00.0851] Slim::Utils::Alarm::_alarmEnd (1966) Ignoring > unwanted notification: playlist stop > > But on the failed one, the alarmEnd (1970) is not ignored and the alarm > is stopped and the device shutdown within two seconds of the alarm being > triggered. > > [22-08-10 12:30:00.0556] Slim::Utils::Alarm::_startStopTimeCheck > (1884) Starting time checker task > [22-08-10 12:30:00.0594] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd > called with request: stop > [22-08-10 12:30:00.0599] Slim::Utils::Alarm::_alarmEnd (1992) Stopping > alarm > [22-08-10 12:30:00.0612] Slim::Utils::Alarm::popAlarmScreensaver (1866) > Attempting to pop alarm screensaver. Current mode: INPUT.List > [22-08-10 12:30:01.0628] Slim::Utils::Alarm::__ANON__ (901) Restoring > pre-alarm shuffle mode: 0 > [22-08-10 12:30:01.0644] Slim::Utils::Alarm::__ANON__ (905) Restoring > pre-alarm power state: off > > Kev One of the things I think I've noted is that the problem always seems to occur when plugin updates are waiting... now whether that's a coincidence and it's just a length of time LMS has been running thing will need some further testing. Good stuff though hopefully this can be sorted. Kev ------------------------------------------------------------------------ KeBul's Profile: http://forums.slimdevices.com/member.php?userid=32883 View this thread: http://forums.slimdevices.com/showthread.php?t=116649 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
