[Power] Implemented power-up/down functionality

[schreibubi]

Implement all the required functionalities to shut-down the tvheadend server when it is idle and restart the tvheadend server before an upcoming recording.

[EricV]

While I don't argue this can be useful, I may suggest that unless tvheadend is the only function that needs to wakeup/sleep the device this is not the right place to take this sleep/restore decision: it should be a centralized and tvheadend being only a client. If other software programs the RTC (or even if something is programed directly in the BIOS) it may well screw up the other wakeup

[schreibubi]

@EricV Do you know a deamon under linux which does this? I don't. And I agree this would be the most useful approach. Maybe I should talk to the systemd guys... ;-)
Anyway, the integration of such a daemon could be done already with the current patch through adapting the shell scripts which are responsible for setting the wake-up/executing the shutdown:

• In preshutdown.sh the daemon needs to be contacted and asked if it is okay to shutdown
• In setwakeup.sh the daemon needs to be told when the next wakup needs to be scheduled
• In shutdown.sh the daemon is asked to shutdown if nothing else is inhibiting the shutdown.

And if you look at all the other PVR solutions (vdr, mythtv) all of them are offering a similar functionality implemented in the same way.

[adamsutton]

@schreibubi funnily enough I do, having hacked on an earlier version, powernapd.

Unfortunately there was a difference of opinion and also I stopped suspending my server. But I've suggested integration into this before.

[EricV]

Well for long I planned to write a small one but given the time I have to effectively program something it never really started. My idea was to reuse the scheduling recording database code from tvhreadend and transform it to a activity period database and add various interface to it to be able to program it via a browser, a socket or a qt client and then use rtcwake code from util-linux to program the clock.

[schreibubi]

@EricV, @adamsutton Yeah would be nice to have such a daemon, but I neither have the time to implement this or extend an existing daemon.

Looking a powernapd it seems to only support shutdown on detecting idle, but no programming of the wake-up time.

I also wouldn't like to tightly integrate tvheadend with one specific daemon, but only provide all the required interfaces and let the user choose the solution he likes best.

I currently see two scenarios which would need to be supported, which differ who is the master for programming the rtc and executing the shutdown.

1. Other daemon (e.g. powernapd) is the master for programming the rtc/executing the shutdown when idle. Here tvheadend needs to tell the daemon which is the next rtc wake-up time to program and also communicate its idle status. In the current patch, the communication for the rtc can be done with the setwakup.sh script. What is currently missing is a script which is executed when the tvheadend idle status changes to inform the other daemon about if we are idle or not.
2. Tvheadend is the master for programming the rtc and executing the shutdown. Here the idle status of another daemon can be checked in the preshutdown.sh script, and the shutdown inhibited if required.

So the only thing missing in my patch would be to implement an additional script which is called when the idle status of tvheadend changes. What do you think?

Any other issues you have seen regarding my patch?

[EricV]

It is not because a program is idle at the time you look at it that it can be shut down for unknwon period of time or you have to know know exactly how the entire programs set running on the machine behaves. Think about a DMS for example. It usually sleeps unless someone ask for accessing recordings but must send ssdp:alive periodically to be discovered asynchronuously. A bittorrent cleint will also need to maintain UPnP IGD ports open even when idle (on a NAS).

Then going to sleep is one thing but you expect to wake up to see your recordings unless you record them on another device (not the usual case). There is a bunch of things you might need to program (USB wakeup for mouse, keyboard, remote, wol feature for ethernet, wonwl for WiFi). So if you plan tvheadend to be the master, please add a script that should cover all theses and enable wakeup on events. See /usr/share/doc/pm-utils/README.debugging for an idea about the complexity.

[schreibubi]

If you want such sophisticated power management, then tvheadend should be the slave. But IMHO 90% of your users will not need this. Then the solution where tvheadend is the master is sufficient (as you can see from all the other vdrs using that solution). For me it is enough to wake my Server through wol. By using the scripts every user can adapt the fuctionality to suit his use case. What is wrong about that?

[EricV]

Don't get me wrong: there nothing I really dislike and I even agree it is useful for many use cases. I just wanted to highlight the difficulties you may introduce for people when enabling this function:

1. you agreed WOL is indeed needed to access your recordings,
2. WOL on WiFi and especially USB wifi chipsets is rather tricky,
3. More and more HTPC will use WiFi 11ac,
4. WOL sometimes works on suspend to RAM (S3) but not always in (S5) mode on several devices I know (because of bugs),

So make sure:

1. This feature is really configurable to retain old behavior,
2. Pass the ethernet devices (list) you want to use for WOL on the scripts (meaning it should probably be be settable on the GUI) because if you need to issue ethtool/specific Wifi command in the script to enable WOL before shutdown, you will need the info. I would also add a shutdown (S5) vs suspend to RAM (S3) option. Ok its in a script but if 90% people need to modify the script then expect many support/feature request. I do not understand why you have a script that just program the RTC via rtcwake and a separate shutdown command. rtcwake is capable of doing both and has many more option to the -m command (including off that indeed calls shutdown but for people wanting S3 its simpler to modify). So at least also use rtcwake for the shutdown script.
3. I would find handy a "shutdown once recording is finished" option when programming a recording,

[stefansaraev]

embedded users would hate you for this. you know. sudo, bash-isms..

[schreibubi]

@stefansaraev The bash-isms I can avoid, but sudo? What do you propose to use instead? On my server tvheadend runs as a seperate user, so I need sudo to execute the shutdown.

[stefansaraev]

dunno, this is a grey area and you know that. why not talk to systemd (logind) via dbus ?
oh. right. debian/ubuntu dont have systemd (yet), so upower? right, it is ubuntu specific.

my point is: a feature that works for you (or requires a specific distro / tools installed) is worthless if the world (other people / distros) can't benefit :)

EDIT: and there are the BSDs (tvheadend do support *bsd), so they might hate you too ;)

[EricV]

@stefansaraev Systemd, dbus for embedded systems? NAS that still runs on ARM have seldom real WOL on S5, no ACPI usually. And just to correct your sentence, systemd has already landed in Debian unstable. rtcwake is in util-linux but more problematic most of the suspend/resume/wakeup is mostly based on ACPI nowadays and thus Intel.

[adamsutton]

Just to throw in my 2 pence, personally I don't like this feature (at least not in the general sense).

Although I can understand that for someone running a dedicated, single app, server for TVH, they might wish to have it responsible for power management. This is not the norm, most users probably run TVH or a shared box that's doing a bunch of different things (in my case, it's my file server and a few other things).

Personally I believe power management should be managed by a dedicated power manager (such as powernapd). Having hooks that can call user defined routines, or visa versa (scripts in pwrmgr that can interface into TVH) is fine, but no more than that.

Adam

[stefansaraev]

@EricV exactly! :) I was about to write just the same as @adamsutton did ^

[andyb2000]

Just to add my own thoughts into this, I implemented something vaguely similar into mine, however I did it externally to TVH as I didn't think it was 'part' of TVH itself. I used the API/status page in the init scripts to determine current TVH activity and then take action appropriately. As mentioned above, I think this is the clearer way forward rather than modfying tvh to have any form of system/power management.
We simply export the ability to determine the current state of TVH, it's next recording time, current subscriptions/activity, etc, and permit a 3rd party application to the take appropriate action. I, for one, would not suggest TVH should have system-level abilities like power, etc.

Again, probably just my point of view+thoughts.

[perexg]

@fda77 : use dbus interface - there is dvr next time signal.. you may use support/dbus_test.py to show these signals.. adding this value to the post-processor script is the bad idea because this value can be changed anytime (when user changes the dvr schedule)

[Hedda]

This might be dead now, but FYI, the terminology this feature is called "real-time clock alarm" when talking about the standard computer BIOS/UEFI functionality which is built-into most computers based on ACPI BIOS or UEFI and have a RTC (Real-Time Clock).

https://en.wikipedia.org/wiki/Real-time_clock_alarm

The feature is also often refered to as WoRTC (Wake on RTC) or WOT (Wake-On-Time), the latter abbreviation WOT I believe was chosen because it follow a similar name-standard to WOL (Wake-On-LAN).

Btw, I think that this is a very nice DVR set-top box appliance-like function to have for a PVR software like Tvheadend, and it is also a feature which is available in MythTV, see: http://www.mythtv.org/wiki/ACPI_Wakeup

[git-developer]

Just for the record and probably years too late:

While I don't argue this can be useful, I may suggest that unless tvheadend is the only function that needs to wakeup/sleep the device this is not the right place to take this sleep/restore decision: it should be a centralized and tvheadend being only a client. If other software programs the RTC (or even if something is programed directly in the BIOS) it may well screw up the other wakeup

This idea was taken into account for the development of git-developer/autosuspend and languitar/autosuspend.