gharris999;399679 Wrote: > How about this as an alternative: optionally, if SrvrPowerCtrl senses > resume OTHER than within 5 minutes of the scheduled wakeup time (i.e. > something other than our RTC setting has caused the resume), no SN pull > back will occur. > > Or will that be just too confusing?
Sounds like a good idea. Your solution would avoid idle switches, and switches can potentially go wrong. However, since alarm detection works only on SC, alarm detection is unfortunately dependent on switchback. I wanted to write stateless code: - Answering the question "would we interrupt a stream on player X by switching back?" was valid in any circumstance. - Every time the server goes to sleep, it queries all local players for the next alarm date, and programs the RTC with the result, regardless of the previous RTC schedule. Since players switch back when SC is up, there is a good chance to truly elect the next alarm. This logic incidentally takes care of the borderline (?) case of an alarm time being modified while under SN, if SC has time to download SN preferences (syncprefs includes the alarms) before sleeping again. But it also breaks completely when the player that is not being switched back is the one with the next alarm --and with a single player, this may happen :) ; in this very case, the next alarm will go undetected, even if the RTC was correctly programmed before the unscheduled server wake-up. At the expense of potentially waking the server for nothing, I could use your strategy along with a stack of RTC dates (saved to disk, for reboots): - before every sleep/poweroff event, query all local players for alarms - push the dates to an RTC dates stack - re-sort the RTC stack, chop off dates now in the past, copy the top date to the OS RTC alarm - save the list - go to sleep. This way, in case a player has not returned, its alarm may still be honored. But if its alarms were modified under SN and the player has not returned, that will be a miss. Also, alarms removed/changed by the user will persist in the server, causing idle server wake-ups ; Tying RTC dates in the stack to the player ID could help weed off obsolete RTC alarm dates, for players that could be queried again... All in all, I think this is kludgy (and very much stateful.) Wouldn't it be better to do nothing, until a reliable way of querying alarms and status under SN has emerged ? -- epoch1970 ------------------------------------------------------------------------ epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711 View this thread: http://forums.slimdevices.com/showthread.php?t=48521 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
