------------------------------------------------------------------------
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)
------------------------------------------------------------------------
gordonb3 - thanks for all your efforts on this, I can't comment on
specifics as most of it is way beyond me, spaghetti code fix is
interesting though.
This morning, I changed my alarm settings to run a sequence of alarms
from 11:30, I used the default web UI and can categorically state I have
not used Material, yesterday or today... But so far today both the 11:30
and 11:45 alarms have failed in the usual way, no alarm screensaver pop
and no stream or fallback sound.
Logfile shows the usual:
[22-11-23 11:30:00.0627] Slim::Utils::Alarm::_alarmEnd (1970) _alarmEnd
called with request: stop
[22-11-23 11:30:00.0647] Slim::Utils::Misc::msg (1325) Warning:
[11:30:00.0642] (
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 =>
"/5e4ba0d7/slim/playerprefs/00:04:20:26:1d:b9|31||5e4ba0d7|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: fired event",
) at /usr/local/slimserver/Slim/Utils/Alarm.pm line 1986.
[22-11-23 11:30:00.0653] Slim::Utils::Alarm::_alarmEnd (1987) Unknown
source:
/5e4ba0d7/slim/playerprefs/00:04:20:26:1d:b9|31||5e4ba0d7|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
[22-11-23 11:30:00.0657] Slim::Utils::Alarm::_alarmEnd (1997) Stopping
alarm
[22-11-23 11:30:00.0670] Slim::Utils::Alarm::popAlarmScreensaver (1866)
Attempting to pop alarm screensaver. Current mode: INPUT.List
[22-11-23 11:30:01.0740] Slim::Utils::Alarm::__ANON__ (901) Restoring
pre-alarm shuffle mode: 0
[22-11-23 11:30:01.0750] Slim::Utils::Alarm::__ANON__ (905) Restoring
pre-alarm power state: off
So despite Michaels feeling that the "playerprefs" source is a red
herring, I'm still only seeing failures when such a source is presented,
in todays case though, no Material involvement only use of the default
Web UI to change the alarm times, not player swapping either - the ui
was on "spare Radio 2" when it opened (and still is) I clicked on
Settings, then the player tab which had "Spare Radio 2" selected and
changed the drop down to Alarm Clock.
And now as I type with no further action taken the 12:00 alarm has
successfully gone off...
_source => "ALARM",
I wonder what produced that brief period of "playerprefs" source
(default web ui? ) and does it as Michael now believes make no
difference.
This whole thing is crazy!!
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
