Bugzilla – Bug 10198
SBC should WOL the SC server for alarms
Last modified: 2011-01-14 00:40:51 UTC
Rationale: most server hardware will respond to wol requests. If the SBC could be aware of the next scheduled alarm for the currently selected player, it could send a wol packet in a timely fashion so that the server could "serve" the scheduled alarm. This would allow users to schedule power off or S3 sleep for their servers and thus make the whole SlimDevices system more "green." Implementation idea: if the SqueezeCenter "alarms" CLI could be extended to include a "next" tag and if the CLI request returned the number of seconds until the next scheduled, enabled alarm for the player, the SBC could then count down until a fixed time before the alarm (next - 300 seconds?) and then issue the wol packet. The SBC could regularly request the [playerid alarms next] info from the server and reset its countdown in response to changing alarm settings.
Tom, is this yours?
This should be addressed when 7.4 code is merged
Moving to the product SqueezePlay because this bug appears to apply to any player based on that application code. Feel free to move it back if it's specific to the single original product.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Tom: I believe you did some WOL work on SP. Is WOL already happening for alarms?
wol is not happening for alarms. I'm marking this as bug_meeting to define what target this should be. I think we should have a needs_target keyword or milestone (since untargeted often mean, no one has looked at it, which is different.)...
NOTE: this is currently working for Radio, failing for SBC