------------------------------------------------------------------------ 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: > > 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... mherger wrote: > > 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. ------------------------------------------------------------------------ gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=116649 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
