I have set up a DVB-T recorder and player based on Debian GNU/Linux, VDR and the plugins vdr-softdevice and vdr-subtitles. The most important modifications I have made will be available here until they have been included in the official releases.
VDR 1.5.1 includes rewritten shutdown logic by Udo Richter. He has also prepared a patch against VDR 1.4. I have adapted VDR some plugins to take advantage of his patch, to suspend the output when the system is running unattended.
Please note that the global variable
was renamed to
when Udo Richter’s patch version 0.4 was applied to VDR
1.5.1. The following patches require VDR 1.5.1 or Udo Richter’s patch version 1.0 or later
This is the preferred way of suspending the output, and it is
incompatible with my
Suspend patch, which is available for
This section is available for historical reasons. The preferred solution is Udo Richter’s shutdown rewrite.
The vdr-softdevice plugin can be
configured to suspend and resume video and audio playback at run time.
This is useful if the system is running unattended, because it saves
processing power (possibly reducing the need for cooling) and avoids
crashes due to bugs in the decoder, possibly triggered by bad input
signal. Because of technical limitations of the plugin interface, I
wrote a patch to introduce a
suspend flag in VDR itself.
After you have applied the patch, recompile vdr and plugins.
The patch introduces three
Miscellanous menu items.
Power button suspends playback and
Playback suspended should be self-explanatory. The
Suspend to shutdown timeout (s), is 0 by default,
meaning that no shutdown will be initiated when playback is suspended
by pressing the
Power button. If you would like to use the
Power button as a smart power-off button that works in any
context, set this timeout to a suitable value, e.g., five seconds.
Should you only want to suspend playback and not power the system off,
you can press
Power followed by
OK. The latter
button-press will confirm the
Press any key to cancel shutdown
prompt if one is presented. (If any timed recordings are in progress,
the prompt will be presented after they have finished, unless the
shutdown was cancelled by pressing any button.)
Be sure to use vdr 1.3.32 or later, because otherwise a long press
of the button will confirm any
Press any key to cancel shutdown
prompt. If you are using the DirectFB output of the vdr-softdevice plugin, be
sure to use recent versions of both (DirectFB 0.9.23 or later
and vdr-softdevice 0.1.3 or later), or key-repeat events will be
misreported as key-press events.
You may also want to map the ACPI power-button event to the command
config.h, so that plugins can check the presence of
#ifdef SUSPEND_PATCHtests have been removed in order to remove binary incompatibility with plugins depending on
cStatus::SetSuspend(bool)that can be monitored by plugins. Thus, relay control can be efficiently implemented in a plugin.
Powerbutton to the suspend function, and it makes the
suspendflag accessible in VDR setup. The
--relayoptions have been removed.
suspendflag can be toggled by pressing a
Suspendbutton introduced by this patch. The command line option
--suspendcan be used to specify the initial value of the flag (default 0, i.e., not suspended). Optionally, there will be a
--relayoption for specifying a serial interface connected to a solid-state relay (default none, i.e., no relay control).
cDevice::Action()will read live stream from the tuner and supply it only to
cRecordingthreads. It would be better to turn off the tuner completely if no recordings are in progress.
full featuredtuner cards with built-in video decoder may do so too.
kPowerevent when the output is suspended by the user, it could perhaps replace this patch.
By connecting a solid-state relay to the VDR system, it is possible to power on the monitor and speakers only when playback is not suspended.
As there are too many ways to connect a relay to the computer, it
is not appropriate to implement relay interfaces in VDR itself. The
vdr-relay plugin connects the
suspend flag to the serial
interface driving a solid-state relay.
runvdrscript for the plugin. Initially, playback is suspended unless the system was powered on by remote control.
vdr-shutdownscript for programming the nvram-wakeup timer for scheduled recordings.
cx88: do not misreport key-repeat events as key-press: linux-2.6.13-cx88-repeat.patch, linux-2.6.14-cx88-repeat.patch
When testing the range of the remote control unit bundled with my Hauppauge Nova-T PCI 90002, I noticed that the input event interface will report multiple key-press events when a key is being pressed and the connection to the infrared receiver module is interrupted for longer than 120 milliseconds. This may be the right solution for keys for which key-repeat is natural, such as volume level adjustment controls, but most keys in VDR should not repeat.
This patch will ignore repeat codes that arrive after the key-release event has been delivered. The drawback is that when the infrared connection is interrupted while a repeat key is being pressed, no event will be delivered for the key until it is released and pressed again, to flip the RC5 toggle bit.
The ultimate solution would be to rewrite
so that it would translate infrared code frames to key-press or
key-repeat events like
av7110_ir.c does, instead of
relying on the repeat timer magic in
if a key is pressed in rapid succession, the driver will incorrectly
deliver key-repeat events instead of key-press events, asynchronously
to the actual real-world key-press events. Key-release events would
still be delivered after a timeout.
cx88: map RC5 frames to key-press or key-repeat events: linux-18.104.22.168-cx88_input.patch, linux-22.214.171.124-cx88_input2.patch
These are experimental patches to
ir-common.c that map RC5 infrared code frames to
key-press or key-repeat events. These patches, based on ideas taken from
av7110_ir.c, are likely to break things for other users of
ir-common.c. The remote control decoder logic should be
refactored, and more of the logic should be moved to
ir-common.c. For instance,
duplicates much of the code in
With the first patch, there is no delay between the key-press and the first key-repeat event. The second patch discards the first repeated frame, so that key-repeat events are less likely to be generated accidentally.