------------------------------------------------------------------------ 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) ------------------------------------------------------------------------
cpd73 wrote: > Can someone please try using the attached Material version? I've remove > the playerprefs "unsubscribe" > > 39220 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. gordonb3 wrote: > 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 gordonb3 wrote: > > 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 ------------------------------------------------------------------------ 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
