Thread Rating:
  • 0 Vote(s) - 0 Average
[VDR] Powermanagement for XBMC and VDR Backend
Some threads below, there is a Powermanagement for XBMC and TVheadend. Myself I made one for those having VDR as backend. Since I am unable to post files here, I have to link the download from

File on

When changing the configuration, remember to disable/enable the service, otherwise it wont notice the changes. More Infos about installation in the addons changelog ...


- When selecting "Poweroff" in XBMC, your system should well ... power off.

- When planning to use "Suspend" or "Hibernate", your system should also do it,
as well as waking up flawless. Otherwise dont use these options. XBMC should
come up at startup, as well.

- Scheduled wakeups are highly system specific. Therefore I cannot tell you how to
setup this feature for your machine. To set the alarm clock, the service will call
an external script given a "timestamp" parameter. However, assuming your using
Linux-Kernel 2.6 or newer, and your mainboard supports ACPI wakeup the script
would look like this:

echo 0 > /sys/class/rtc/rtc0/wakealarm
echo $1 > /sys/class/rtc/rtc0/wakealarm

If thats the case, you might review the file /etc/default/rcS for having the entries:

- a VDR backend service, would be usefull to be present for this service. :-)


- VDR Host & SVDRP-Port: Those are used to "talk" with your VDR.
- Wakeup before record: Time to boot up, before the timer.
- Wakeuptime command (cmd [timestamp]): Script to call setting the alarm clock.
- Powersave when idle: Do you want to power down or suspend when idle?
- Powersafe after: Idle time until powersave.
- Overrun after playback/record: Extra time when exceeding idle time during record or
- Daily wakeup: Do you want to wake the system once a day?
- Daily wakeup time (HH:MM): When do you want to wakeup?

- This service handles powersave and wakeup timers independant. Therefore it will wakeup
when shutted down by accident or another program than XBMC.

- Timers are checked periodically, sudden changes are to be considered.

- Idle time is defined as not touching the remote, keyboard or mouse. The service takes care
of upcomming and active recordings as well as media playback. For example, if you setup
30 minutes idle timeout and watch a 45 minutes video the system normally should power down
for being idle after playback stops. But the service will give you the "Overrun" time
to wake up yourself and grab the remote. ;-)

- Daily wakeup comes at hand when its about to update your EPGs.

Limitations, known issues:
- Remote commands issued by web Interface, wont reset the idle counter. This is because
XBMC dont handles them like common input.

- The service is unable to detect VDR activities to other clients. Say, you stream TV
towards your local PC, it would not notice it.

- Due to a Bug in XBMC, profiles are not handled very well when it comes to services.
Logging out may result in killing the services, not coming up when logging back again.
So this is doing the same as acpiwakeup addon for VDR right ?
It checks ongoing recordings - but its doesnt check if vdr is busy for other reason ?
There is nothing similar to the hook of vdr covered by lifeguard ?

Thanks for your efforts - will check it soon. What would you need in order to check if vdr is busy (some vdr plugin ? should that be part of xvdr/vnsi plugin ? )

VDR can handle wakeup allready on its own - check vdr-addon-acpiwakeup - the big questionmark is allways : Who takes ownership of this , and how to intercept XBMC - this feature is missing since a long time - making proper integration of XBMC/vdr frontend/backend very difficult ( i would think that 80% of our users are having vdr and XBMC on the same machine ).
I am able to check if something is playing with XBMC as well as being recorded or upcomming to be recorded. When using VDR as backend only on this machine, its fine.

However, if you use VDR to stream TV forward to other clients, the Addon wont notice it. Whats missing is a SVDRP command returning the number of active connections.

Like you said, VDR cannot know about XBMCs activity. You could check this by json, but miss user activities this way. In my opinion the frontend is the right place to control and configure powersaving. For example, when suspend mode is issued by XBMC, its able to exit gracefully, otherwise its needed to be killed, probably with negative effects to databases and such.
steffen_b Wrote:VDR can handle wakeup allready on its own - check vdr-addon-acpiwakeup - the big questionmark is allways : Who takes ownership of this?

The answer is easy. Taleteller and I know about the possibilities of vdr because we are members of the vdr-portal Wink. The answer is what use people as preferred frontend? In case of XBMC as frontend (and headless VDR or TVHeadend or MythTV as backend) it's logical to implement missing features like conditional shutdown and/or timered wakeup into the frontend and so XBMC pushing up into a fullfeatured PVR. Whe are not talking about the many and most nicely plugins that are available with and within vdr. That's another playground.

I'm also vdr-portal resident - so its difficult to turn your mind sometimes Wink I am very happy to see this addon Smile

I also think user activity should be tracked only by frontend - the acpi-wakeup-addon could directly be re-used it only need next timer in UTC seconds since ... this is what vdr provides - if you re-use it you get well tested code Wink

Regarding further activity inside vdr, you know that you should be able to ask for the activity of the plugins in vdr - should be possible also from plugin - streamdev will signal to be active and those not be available for shutdown - this should be done maybe in xvdr/vnsi to be requested optionally or could be done in a seperate plugin.

Regarding next timer - it should also be computed at vdr side re-using vdr code - for communication dbus or restfulapi plugin might be easier to handle svdrp can be busy because its single connection protocol. It might also be easier to be implemented. Also you need to cover possibly the brdge time to the next timer (dont shutdown if timer is X minutes ahead). Another o feature i would miss would be lifeguard addon - well its not easy if you are used to the features for years Wink

This is more braindump / design thoughts to get myself a clearer picture and should not be understood as criticism btw !!!
steffen_b Wrote:Regarding next timer - it should also be computed at vdr side re-using vdr code - for communication dbus or restfulapi plugin might be easier to handle svdrp can be busy because its single connection protocol. It might also be easier to be implemented.
No Wink. Every backend has to provide all needed informations about their actual properties and actions in an uniformed way. Just like an object in an object-oriented environment. This made conversation much easier simple like parsing xml-files (TVheadend) or using SVDRP (VDR). Don't know what MythTV is using.
steffen_b Wrote:This is more braindump / design thoughts to get myself a clearer picture and should not be understood as criticism btw !!!
Excuse me but every hint, every kick or brainstorming to turn it on is very appreciated! You are welcome!

SVDRP was the quickest and easiest way to contact the VDR backend. Another reason, there is plenty of different implementations of XVDR, VNSI (maybe even Streamdev?) in several versions. I am not even sure if its possible to communicate over Phyton with the XVDR Addon, but I have seen people issuing commands using json, so it might be.

Blocking SVDRP was not that big issue. The Addon starts a connection once a minute, gets the timers and disconnects. When its blocked it retries a minute later. It also works fine alongside with VDRadmin-am for example.

Deciding for a shutdown is tricky and vdr.powersave is trying to make "educated guesses". For example: Your shutdown timer is set to one hour, and your recording a movie running two hours. Normally the clock would force a shutdown right after the recoding stops. Therefore I added a so called "overrun". It gives another countdown on the top, giving time for post-recording hooks as well as upcomming records. If any timer (including prerun or overrun) overlaps the system will stay running.

Like steffen said, we miss any auxiliary activities of the VDR side. It would be smart to implement a "INFO" command to SVDRP before starting a whole new game with DBUS. Liveguard is a interesting suggestion, I will watch into it.
The dbus plugin exists allready.
The restfulapi (json,xml) plugin also allready exist. Beside that its up to you Smile

Beside that:

might be usefull to you and should be easy to extend. at the moment it can simulate shutdown and really do a vdr shutdown (the vdr way) - looking inside it should be easy to expose anything needed there.
The vdr-plugin-restfulapi looks promising, might be added as alternative way of polling. Yet it does not solve missing knowledge of auxiliary activities, nor can I count on the dependency.

The vdr-plugin-shutdown is interesting as well. Actually I leave this handling to the system itself. For example, when using S3 as option, you dont want to simply shutdown VDR. You have also to wake it up, and such hooks match best in the /etc/pm/sleep.d processing. Handling it as the service it is, feels most straight to me. I also noticed XVDR is not always happy about loosing contact to vdr, forcing you to restart XBMC at wakeup as well.
to my experience, at least in ubuntu natty you need to stop vdr during S3 else it will break in numerous ways (be it that the DVB drivers crash because the are held open during S3, be it that vdr looses contact to its files/filesystem.

In one of my testsystems i was able to keep vdr running during S3 - prerequesite is vdr dynamite plugin and disconnecting vdr from DVB devices (with just another plugin again -> dynamite Smile ).

The handling of the shutdown of vdr at S3/shutdown doesn't really matter - the problem it tried to solve is to perform all checks VDR usually does with other frontends before doing the shutdown. I mean the framework for that for vdr is working since years and here we try to reinvent the wheel or adapt existing to new requirement Wink.

I strongly believe that parts of this should be part of main PVR feature set.

Handling of connect/reconnect in xvdr/vnsi should be filed a bug and be fixed then. It could also happen that vdr is restarting itself to recover.

I always find myself trapped in "VDR Thinking" Big Grin

"Yet it does not solve missing knowledge of auxiliary activities" - this can be changed.

"nor can I count on the dependency. " why not Smile doesnt matter Smile to rely on a plugin is better then to rely on a patch or a version of vdr Smile
Sorry for getting this out of stasis, but wouldn't it be possible to detect network traffic on the card and determine with that if the counter should be reset or not? I guess you could pretty reliably say that the htpc is in use if the traffic exceeds a certain threshold.
*This whole thread should probably go into the VDR section.

After some fiddling about I managed to get a working netstat check which scans pre defined ports for activity integrated into the powersave service, maybe somebody finds it useful too so here goes (disclaimer: I got no idea what I'm doing and just edited already existing code, see the thanks bit, it works on my end though thats the important bit):

1. Install the powersave service.
2. get the edited and

cd .xbmc/addons/service.vdr.powersafe/resources/lib
wget -O
wget -O

3. edit the ports you want checked in

watched = {
    ('tcp', 22), # SSH
    ('tcp', 3000), # streamdev
    ('tcp', 34891), # xvdr
    ('tcp', 34890), # vnsi
    ('tcp', 49952), # transmission

Thanks a lot to: Taleteller for creating the powersave service, cube for the inhibit_shutdown service where I stole the netstat code and Hobby-Student for pointing me into the right direction regarding integrating it into powersave.

[VDR] Powermanagement for XBMC and VDR Backend00