gharris999;374440 Wrote: > I'm looking closely at your getalarms_2.pl acript and I'm in the process > of adding rtc wakeup capability to the next version of SrvrPowerCtrl. > > For this next version, I think I'll just ignore the whole DST change > problem. Really testing DST change conditions on both Linux & Windows > will take more time than I've got at the moment. Gee... Slim::Utils::Alarm->getNextAlarm() and nobody told me anything ??? :-)) If this sub does the heavy lifting now, then I guess you don't really need to care about DST. Perhaps the server will miss wake-up / wake-up too early and go back to sleep twice in the year; anyway what to do in these corner cases depends on what SBs are programmed to do by SN/SC. I would say a wait and see posture is reasonable.
I suppose you intend to track the player to which belongs the next alarm as part of your code (to get alarm duration, alarm volume (?), willingness to be reconnected to SC if on SN...) I never went to the extent of looking for *each player*'s next alarm in addition to the closest one, but perhaps that could be interesting considering the plugin has a GUI. Server-side, what I do is have a stack of RTC wake alarms. Every time *something* asks for programmed wake-up (99.9% SBs, 0.01% a system event of some sort), I stack up the new alarm. This alarm stack is the only piece of information I store to disk before power state change, so it survives programmed shutdown + restart. When it's sleep/shutdown time I sort the stack, chop off all past alarms, and read the top of the stack (don't pop it off right away, that date will be in the past at some later point and be dealt with) to program the RTC. I'm not using too much sheduled wake-up outside SBs; I thought I needed it for running getmail/postfix (or some other batchers) smoothly but it turns out this was an overkill in my use-case. So I can't see all uses/implications of managing an RTC wake date stack; Sometime the server may wake up for nothing and go back to sleep on idle for sure. But that is the safe behaviour for cases where a player is intermittently unavailable (on SN, on the move, wi-fi problems...) > My Windows development machine is a cranky old box that requires an > hour's worth of updating every time I turn it on. So, I experience a > disincentive every time I try to test new windows features in the > plugin. I feel your pain. I think you should try running a VM. Windows as a guest runs well on VMs; Given your host/OS VM software, your uptime/reliability may vary. But its very handy for dev and testing. 3 killer features: boot/reboot is fast and harmless; you can snapshot the system drive (or manually copy the file) to handle a test config and rollback if necessary; cloning/migrating is as easy as copying a file. I use Virtualbox, which is libre, free and well ported (host and guest -wise). Works very well on my host desktops (macs) and very bad on my main server (linux) but I know the problem belongs in the host OS. Can run headless; I use MS RDC to connect to the boxes in the server. I'm sure there's a bit of time investment at the beginning, but I believe its worth it. > I you'd like to take a crack at those when I post the next version, I'll > be very appreciative. No prob'. I 'll stick around. -- 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/lists/listinfo/plugins
