vdr/INSTALL
Klaus Schmidinger da948a50d2 Version 1.3.38
- Fixed handling second audio and Dolby Digital PIDs for encrypted channels
  (was broken in version 1.3.37).
- Improved TS/PES conversion to better handle lost TS packets (thanks to
  Reinhard Nissl).
- Limited the frequency of log messages from the cRepackers.
- Now using the gettid() syscall to get a thread's pid, so that we get a
  useful value on NPTL systems (suggested by Johannes Stezenbach).
- Fixed the RCU remote control handling to avoid problems with NPTL (thanks
  to Andreas Share for reporting a lockup with the RCU on NPTL systems).
- When displaying the amount of free disk space, the space consumed by
  recordings that have been "deleted" but not yet actually "removed" is now
  taken into account (suggested by Christian Vogt).
- Now avoiding unnecessary disk access when checking if there are deleted
  recordings that need to be removed (reported by Carsten Koch).
- Fixed handling the DELETEDLIFETIME when removing deleted recordings. Now
  a deleted recording is retained at least DELETEDLIFETIME seconds before
  actually removing it.
  The value of DELETEDLIFETIME has been changed to 300. So after (possibly
  inadvertently) deleting a recording, there will be at least 5 minutes
  in which it can be recovered (unless a new recording immediately requires
  the disk space). The count starts again at 0 every time VDR is started.
- Fixed a possible crash when displaying the "Low disk space!" message from
  a background thread (thanks to Christof Steininger).
- Fixed handling OSD areas that have invalid sizes (thanks to Marco Schlüßler).
- Added a mutex to AssertFreeDiskSpace() to make sure calls from foreground
  and background threads won't interfere.
- The main menu now dynamically updates its contents in case an instant
  recording or replay stops, etc.
- The version number of EPG events is now also stored in the epg.data file
  (thanks to Kendy Kutzner).
- EPG events that are no longer in the currently broadcasted data stream are
  now automatically deleted.
- Removed an invalid access to Event->schedule in cSchedule::DelEvent().
- Modified cSchedule::Cleanup() (events are always sorted by time).
- Schedules are now cleaned up once every hour (not only at 05:00).
- The "Schedule" and "What's on now/next?" menus are now updated if a timer
  is set or modified.
- cTimer no longer has its own 'schedule' member, it rather uses that of the
  event it has been set to.
- The "Red" button in the "Schedule", "What's on now/next?" and "Event" menus
  now immediately creates a timer for the selected event and marks it with 'T'.
  If the event is already marked with 'T', the "Red" button opens the "Edit
  timer" menu for that timer.
- Removing deleted recordings is now done in a separate thread.
- Dropped the unused "stop recording on primary interface" stuff.
- Converting a grabbed image to JPEG is now done with the new function
  RgbToJpeg() (see tools.h).
- The SVDRP command GRAB now determines the image type (JPEG or PNM) from the
  extension (".jpg", ".jpeg" or ".pnm") of the given file name. The explicit
  'jpeg' or 'pnm' parameter is still accepted for backward compatibility, but
  has no meaning any more.
- The function cDevice::GrabImage() no longer writes the grabbed image to a
  file, but rather returns a pointer to the image in memory. The wrapper
  function cDevice::GrabImageFile() can be used to write the grabbed image
  directly to a file. Plugins that used the old version of cDevice::GrabImage()
  need to be adapted to the new interface.
- The new class cBase64Encoder (see tools.h) can be used to encode data in
  base64 (thanks to Bob Withers for publishing his Base64 class).
- The SVDRP command GRAB now writes the image data to the SVDRP connection
  (encoded in base64) if the given file name consists of only the file
  extension (".jpg", ".jpeg" or ".pnm"), or if only "-" is given as file
  name (based on a suggestion from Darren Salt).
  A simple way of viewing a grabbed image on a remote host is:

  svdrpsend.pl -d <hostname> 'grab -' | sed -n -e 's/^216-//p' -e '1ibegin-base64 644 -' -e '$a====' | uudecode | display -

- The new command line option '-g' must be given if the SVDRP command GRAB
  shall be allowed to write image files to disk. The parameter to this option
  must be the full path name of an existing directory, without any "..", double
  '/' or symlinks. By default, or if "-g- is given, grabbing to files is
  not allowed any more because of potential security risks.
- Modified the way the SVDRP command GRAB writes the grabbed image to a file
  to avoid a security hole (CAN-2005-0071, reported by Javier Fernández-Sanguino
  Peña):
  + The file handle is now opened in a way that it won't follow symbolic links
    (suggested by Darren Salt).
  + The given file name is now canonicalized, so that it won't contain any
    ".." or symlinks (suggested by Darren Salt).
  + Grabbing to files is limited to the directory given in the the command
    line option '-g'. By default grabbing to files is not allowed any more.
- Updated the Greek OSD texts (thanks to Dimitrios Dimitrakos).
- Changed all "illegal" to "invalid" in error messages (there's nothing "illegal"
  in VDR ;-).
- When started as user 'root' VDR now switches to a lesser privileged user id,
  keeping the capability to set the system time (based on a patch from Ludwig
  Nussel). By default the user id 'vdr' is used, which can be changed through
  the new command line option '-u'. Note that for security reasons VDR will no
  longer run as user 'root' (unless you explicitly start it with '-u root',
  but this is not recommended!). The 'runvdr' script has been changed to
  use the '-u' option.
- Changed the API of the functions cStatus::Recording() and cStatus::Replaying(),
  so that they can provide the full file name of the recording. Plugins that use
  these (or the related cStatus::Msg...() functions) need to be adapted
  (suggested by Andreas Brugger).
- The DVB devices now retune (and, if applicable, resend the DiSEqC data) if
  the lock is lost (based on a patch from Reinhard Nissl).
- Fixed handling multi byte key sequences in cKbdRemote (based on a patch from
  Jürgen Schneider).
- Removed unused variables in skinclassic.c and skinsttng.c (thanks to Marco
  Schlüßler).
- Made the static cControl functions thread safe (thanks to Patrick Fischer).
- Fixed initializing pthread_mutexattr_t and pthread_rwlockattr_t to avoid
  warnings with g++ 4.1.0 (thanks to Ville Skyttä).
- Fixed incrementing the 'state' variables in the repacker classes in remux.c
  to avoid warnings with g++ 4.1.0 (reported by Ville Skyttä).
- The Makefile now reports a summary of failed plugins (thanks to Udo Richter).
- The cTimer constructor can now take an optional cChannel (suggested by
  Patrick Fischer).
- Fixed setting the main thread id if VDR is running as a daemon.
- Fixed handling TS packets in cTS2PES (thanks to Reinhard Nissl).
- Added cTimer::SetPriority() to set a timer's priority (suggested by Kendy Kutzner).
- Added cMenuEditStrItem::InEditMode() (suggested by Christian Wieninger).
- Now using FE_READ_STATUS to read the current frontend status (suggested by
  Holger Wächtler).
- The "Menu" key now behaves consistently. If there is anything on the OSD, it
  is closed when the "Menu" key is pressed, and if there is nothing on the OSD,
  the "Menu" key opens the main menu (suggested by Luca Olivetti).
- The new option "Setup/OSD/Timeout requested channel info" can be used to turn
  off the automatic timeout of the channel display in case it was invoked by
  a press of the "Ok" key (suggested by Thiemo Gehrke).
- A message is now given when an instant recording is started (suggested by
  Helmut Auer). Actually the code was already there, just commented out - don't
  remember why it wasn't active...
- Removed an obsolete "Summary" text from i18n.c and preceded all key definition
  texts with "Key$" to avoid duplicates (reported by Lucian Muresan).
- Preceded all button texts with "Button$".
- Removed obsolete "Eject", "Language" and "scanning recordings..." texts.
- Added missing #include "thread.h" to dvbspu.c (reported by Gavin Hamill).
- Disabled the use of "fadvise" in cUnbufferedFile because there have been
  several reports that it causes more problems than it solves (suggested by
  Petri Hintukainen). If you want to use "fadvise", you can activate the line
  //#define USE_FADVISE
  in tools.c.
- Removed unused 'offset' member from cOsdItem.
- In the "Channels" menu the numeric keys now position the cursor to the channel
  with the given number (see MANUAL, section "Remote Control Keys", note (3) for
  details).
- The "Mark/Move" function in the "Channels" menu now also works in the non-numeric
  sort modes.
- The default cOsdObject::Show() now automatically calls cOsdMenu::Display() if
  this is a menu.
- The new "Info" key brings up information on the currently viewed programme
  or recording. For a live programme this is the same as "Schedule/Ok", i.e. the
  description of the current EPG event. For a recording this is the same as shown
  by the "Info" button in the "Recordings" menu. Plugins that implement players
  can overwrite their cControl::GetInfo() function to show their own info (see
  PLUGINS.html for details). Pressing the "Info" key again while the info is
  displayed will close the OSD. In order to assign this new key to an existing
  remote control setup, the remote.conf file needs to be deleted and VDR has
  to be restarted to go through the process of learning the remote control keys.
- Any cReceivers still attached to a cDevice when that device switches to a
  different transponder are now automatically detached (suggested by Patrick
  Fischer).
- The "flags" of a timer are now handled as an unsigned integer value. In order
  to do this, the interface of cMenuEditBitItem also had to be changed.
- In string entry fields (like, e.g., the file name of a recording) the characters
  can now be entered by pressing the numeric keys, the same way as on a
  telephone keypad (based on the "Easy Input" patch from Marcel Schaeben).
- Fixed the "Day" field of the "Edit timer" menu when pressing '0' to switch
  from "single shot" to "weekly", followed by the "Right" key (reported by
  Andreas Böttger).
- The file 'ca.conf' is obsolete and has been removed.
- Revised all descriptions regarding CICAM.
- Adapted c(Dvb)Device::ProvidesCa() to the dynamic CA handling.
- Added a mutex to synchronize cDevice::PlayPesPacket() and SetCurrentAudioTrack()
  (thanks to Reinhard Nissl).
- Added a SleepMs() in cRecorder::Action() to avoid a busy loop (thanks to Ingo
  Schneider).
- Cleaned up some trailing white space.
2006-01-08 18:00:00 +01:00

415 lines
18 KiB
Plaintext

Installation of the Video Disk Recorder
---------------------------------------
Version 1.3
-----------
IMPORTANT NOTES:
----------------
Please make sure your environment is NOT set to use UTF-8 or
any other multibyte character representation. Check the value of your
$LANG or $LC_CTYPE environment variable, and if it contains something
like "de_DE.UTF-8", make sure you set it to something like "de_DE.iso8859-1"
or whatever single byte character mode you want. If you run VDR with
UTF-8 enabled, it may crash in case it encounters EPG or channel data
that contains non-7-bit ASCII characters. Another problem may occur if
you have mounted your video partition with "iocharset=utf8". In that case
recordings that contain umlauts or other non-seven-bit ASCII characters
may be displayed wrong, or not at all. Please make sure you mount your
video partition with "iocharset=iso8859-1" or whatever single byte character
mode you want.
Compiling and running the program:
----------------------------------
VDR requires the Linux-DVB driver header files to compile.
As of kernel 2.6 these are part of the official Linux kernel
distribution, and VDR's Makefile will automatically locate
them. If you are using kernel 2.4 or earlier, you should
install the files from this package in a directory that is
"parallel" to the DVB directory of the driver source (refer to
http://linuxtv.org for more information about that driver).
For example, if the DVB driver was extracted into the directory
/home/kls/vdr/DVB, then this package should be extracted into
/home/kls/vdr/VDR.
If you have the DVB driver source in a different location
you can rename the file Make.config.template to Make.config and
adjust the definition of DVBDIR in that file.
VDR requires the Linux-DVB driver version dated 2003-08-23 or higher
to work properly.
After extracting the package, change into the VDR directory
and type 'make'. This should produce an executable file
named 'vdr', which can be run after the DVB driver has been
installed.
IMPORTANT: See "Configuration files" below for information on how
========= to set up the configuration files at the proper location!
By default the 'vdr' program can be controlled via the PC keyboard.
If you want to disable control via the keyboard, you can add NO_KBD=1
to the 'make' call, or use the '--no-kbd' option at runtime.
If you have an infrared remote control unit you can define the REMOTE macro
to one of the following values in the 'make' call to make the respective control
the default:
REMOTE=RCU control via the "Remote Control Unit" receiver
(see http://www.cadsoft.de/vdr/remote.htm)
REMOTE=LIRC control via the "Linux Infrared Remote Control"
(see http://www.lirc.org)
Alternatively you can use the '--rcu' or '--lirc' options at runtime.
These options accept an optional path to the remote control device,
which's defaults can be set via the RCU_DEVICE and LIRC_DEVICE macros,
respectively.
If your video directory will be on a VFAT partition, add the compile
time switch
VFAT=1
to the 'make' command. Alternatively, you can call VDR with the command
line option '--vfat'.
When running, the 'vdr' program writes status information into the
system log file (/var/log/messages). You may want to watch these
messages (tail -f /var/log/mesages) to see if there are any problems.
The program can be controlled via a network connection to its SVDRP
port ("Simple Video Disk Recorder Protocol"). By default, it listens
on port 2001 (use the --port=PORT option to change this). For details
about the SVDRP syntax see the source file 'svdrp.c'.
WARNING: DUE TO THE OPEN SVDRP PORT THIS PROGRAM MAY CONSTITUTE A
======= POTENTIAL SECURITY HAZARD! IF YOU ARE NOT RUNNING VDR IN
A CONTROLLED ENVIRONMENT, YOU MAY WANT TO DISABLE SVDRP
BY USING '--port=0'!
The file 'svdrphosts.conf' can be used to define which hosts are allowed
to access the SVDRP port. By default only localhost (127.0.0.1) is granted
access. If you want to give other hosts access to your SVDRP port you need to
add their IP numbers to 'svdrphosts.conf'.
If the program shall run as a daemon, use the --daemon option. This
will completely detach it from the terminal and will continue as a
background process.
When starting the program through an entry in /etc/inittab, use the --terminal
option to set the controlling terminal, as in
vdr:123:respawn:/usr/local/bin/vdr --terminal=/dev/tty8 -w 60
See the man page vdr(1) for complete information about all command line options.
Locale
------
When presenting the list of recordings, VDR sorts the entries according to
the current "locale" settings. This makes sure that special characters (like
the German "umlauts") appear at the expected positions. In order to benefit
from this you may have to set the locale environment variable, for instance
export LANG=de_DE
for a German locale. If you don't want this to result in German error messages
in the log file, it is sufficient to just set
export LC_COLLATE=de_DE
which only influences the way strings are sorted and leaves error messages
in English.
Automatic restart in case of hangups:
-------------------------------------
If you run VDR using the 'runvdr' shell script it will use the built-in
watchdog timer to restart the program in case something happens that
causes a program hangup. If you change the command line options for the
call to the VDR program, be sure to NOT use the '-d' option! Otherwise
VDR will go into 'deamon' mode and the initial program call will return
immediately!
Setting the system time:
------------------------
If you want VDR to set the system time according to the data received
from the transponder, you need to start VDR as user 'root'. VDR will
then only keep the capability to set the system time, and set its
user id to a lesser privileged one ('vdr' by default, can be set
to a different value with the '-u' option).
You also need to enable the "EPG/Set system time" option in VDR's
Setup menu, and select a transponder from which you want to receive
the time in "Use time from transponder". Make sure you select a transponder
that has a reliable clock - some transponders are quite off.
Automatic shutdown:
-------------------
If you define a shutdown command via the '-s' command line option, VDR
will call the given command if there is currently no recording or replay
active, the user has been inactive for at least MinUserInactivity minutes
and the next timer event is at least MinEventTimeout minutes in the future
(see the Setup parameters in MANUAL).
The command given in the '-s' option will be called with five parameters.
The first one is the time (in UTC) of the next timer event (as a time_t
type number), and the second one is the number of seconds from the current
time until the next timer event. Your program can choose which one to use
for programming some sort of hardware device that makes sure the computer
will be restarted in time before the next timer event. Your program must
also initiate the actual shutdown procedure of the computer. After this
your program should return to VDR. VDR will not automatically exit after
calling the shutdown program, but will rather continue normally until it
receives a SIGTERM when the computer is actually shut down. So in case
the shutdown fails, or the shutdown program for some reason decides not to
perform a shutdown, VDR will stay up and running and will call the shutdown
program again after another MinUserInactivity minutes.
If there are currently no timers active, both parameters will be '0'.
In that case the program shall not set the hardware for automatic restart
and only perform the system shutdown. A program that uses the second parameter
to set the hardware for restart must therefore also check whether the first
parameter is '0'.
The third parameter contains the number of the channel that will be recorded
by the next timer (or 0 if no timer is present), and the fourth parameter
contains the file name of the recording as defined in the timer (or an empty
string if no timer is present). These can be used by the shutdown program to
show that information on some display interface etc.
The fifth parameter indicates the reason why the shutdown was requested.
'0' means this is an automatic shutdown due to some timeout, while '1' means
that this is a user requested shutdown (resulting from pressing the "Power"
key). The shutdown program may use this information to decide whether or
not to actually perform the system shutdown.
If a timer is currently recording, the parameters will reflect the start
time of that timer. This means that the first parameter will be a time in
the past, and the second parameter will be a negative number. This only
happens if the user presses the "Power" key while a timer is currently
recording.
Before the shutdown program is called, the user will be prompted to inform
him that the system is about to shut down. If any remote control key is
pressed while this prompt is visible, the shutdown will be cancelled (and
tried again after another MinUserInactivity minutes). The shutdown prompt
will be displayed for 5 minutes, which should be enough time for the user
to react.
A sample shell script to be used with the '-s' option might look like this:
#!/bin/sh
setRTCwakeup $(($1 - 300))
sudo halt
Here 'setRTCwakeup' would be some program that uses the first parameter
(which is the absolute time of the next timer event) to set the Real Time
Clock so that it wakes up the computer 5 minutes (i.e. 300 seconds) before
that event. The 'sudo halt' command then shuts down the computer.
You will have to substitute both commands with whatever applies to your
particular hard- and software environment.
If the '-s' option is present, the VDR machine can be turned off by pressing
the "Power" key on the remote control.
Executing commands before and after a recording:
------------------------------------------------
You can use the '-r' option to define a program or script that gets called
before and after a recording is performed, and after an editing process
has finished.
The program will be called with two string parameters. The first parameter
is one of
before if this is *before* a recording starts
after if this is *after* a recording has finished
edited if this is after a recording has been *edited*
and the second parameter contains the full name of the recording's
directory (which may not yet exists at that moment in the "before" case).
In the "edited" case it will be the name of the edited version.
Within this program you can do anything you would like to do before and/or
after a recording or after an editing process. However, the program must return
as soon as possible, because otherwise it will block further execution of VDR.
Be especially careful to make sure the program returns before the watchdog
timeout you may have set up with the '-w' option! If the operation you want to
perform will take longer, you will have to run it as a background job.
An example script for use with the '-r' option could look like this:
#!/bin/sh
case "$1" in
before)
echo "Before recording $2"
;;
after)
echo "After recording $2"
;;
edited)
echo "Edited recording $2"
;;
*)
echo "ERROR: unknown state: $1"
;;
esac
Command line options:
---------------------
Use "vdr --help" for a list of available command line options.
Replaying Dolby Digital audio:
------------------------------
If you have a "full featured" DVB card with SPDIF output you can replay
Dolby Digital audio directly through the DVB card.
You can also use an external program that reads the DD data
from stdin and processes it in a way suitable for your audio hardware.
This program must be given to VDR with the '-a' option, as in
vdr -a ac3play
The video data directory:
-------------------------
All recordings are written into directories below "/video". Please
make sure this directory exists, and that the user who runs the 'vdr'
program has read and write access to that directory.
If you prefer a different location for your video files, you can use
the '-v' option to change that. Please make sure that the directory
name you use with '-v' is a clean and absolute path name (no '..' or
multiple slashes).
Note that the file system need not be 64-bit proof, since the 'vdr'
program splits video files into chunks of about 2GB. You should use
a disk with several gigabytes of free space. One GB can store roughly
half an hour of video data.
If you have more than one disk and don't want to combine them to form
one large logical volume, you can set up several video directories as
mount points for these disks. All of these directories must have the
same basic name and must end with a numeric part, which starts at 0 for
the main directory and has increasing values for the rest of the
directories. For example
/video0
/video1
/video2
would be a setup with three directories. You can use more than one
numeric digit, and the directories need not be directly under '/':
/mnt/MyVideos/vdr.00
/mnt/MyVideos/vdr.01
/mnt/MyVideos/vdr.02
...
/mnt/MyVideos/vdr.11
would set up twelve disks (wow, what a machine that would be!).
To use such a multi directory setup, you need to add the '-v' option
with the name of the basic directory when running 'vdr':
vdr -v /video0
Note that you should not copy any non-VDR files into the /videoX directories,
since this might cause the watchdog timer to expire when VDR cleans up those
directories and there is a large number of files and/or subdirectories in
there.
Configuration files:
--------------------
There are several configuration files that hold information about
channels, remote control keys, timers etc. By default these files are
assumed to be located in the video directory, but a different directory
can be used with the '-c' option. Plugins assume their configuration files
in a subdirectory called "plugins" of this directory.
For starters just copy all *.conf files from the VDR directory into your
video directory.
The configuration files can be edited with any text editor, or will be written
by the 'vdr' program if any changes are made inside the on-screen menus.
Take a look at man page vdr(5) for information about the file formats.
The files that come with this package contain the author's selections,
so please make sure you adapt these to your personal taste. Also make sure
that the channels defined in 'channels.conf' are correct before attempting
to record anything. Channel parameters may vary and not all of the channels
listed in the default 'channels.conf' file have been verified by the author.
As a starting point you can copy the 'channels.conf' file that comes with the
VDR archive into your video directory (or into your config directory,
respectively, in case you have redirected it with the -c option).
Setting up DiSEqC:
------------------
If you are using a DVB-S card with a satellite equipment that needs to be
accessed using DiSEqC, you have to go to the "Setup" menu and set the "DiSEqC"
parameter to "on". You also need to set up the file 'diseqc.conf' to properly
access your DiSEqC equipment (see man vdr(5) for details).
Running VDR with DVB-C (cable) or DVB-T (terrestrial):
------------------------------------------------------
VDR automatically recognizes if the DVB card in use is a cable or a
terrestrial card. The only thing that needs to be different when using digital
cable or terrestrial reception is the 'channels.conf' file. The distribution
archive contains a default 'channels.conf.cable' and 'channels.conf.terr',
respectively, which users of such cards can rename or copy to 'channels.conf'
in order to receive digital cable or terrestrial channels. The format of these
files is mostly the same as for satellite channels, however, some fields have
different or extended meanings (see man vdr(5) for details).
You can even use a mixture of DVB-S, DVB-C and DVB-T cards in the same system.
All you need to do is to put all the channel definitions into one big
'channels.conf' file. VDR will automatically know which channels can be
received with which card(s) by evaluating the 'source' parameter.
Learning the remote control keys:
---------------------------------
There is no default 'remote.conf' file, so you will have to go through a "teach-in"
session that allows the program to learn your remote control codes.
It will first attempt to determine the basic data transfer mode and
timing of your remote control unit, and then will ask you to press one
key after the other so that it can learn the various key codes. You will
at least need to provide an "Up" and a "Down" key, so that you can switch
channels. The rest of the key definitions is optional, but the more keys
you define, the more you will be able to navigate through the menus and
control recording/replaying. The program uses only a very small number
of keys which have multiple meanings in the various modes (see MANUAL
for a detailed description).
The recommended PC key assignments are:
Up, Down, Left, Right Crsr keys in numeric block
Menu 'Home' in numeric block
Ok 'Enter'
Back 'End' in numeric block
Red, Green, Yellow, Blue 'F1'..'F4'
0..9 '0'..'9' in top row
Power 'P'
Volume+/- '+', '-'
Mute 'm'
If you prefer different key assignments, or if the default doesn't work for
your keyboard, simply delete the file 'remote.conf' and restart 'vdr' to get
into learning mode.
Generating source code documentation:
-------------------------------------
You can do a 'make srcdoc' to generate source code documentation using the
Doxygen tool. To do so you need the Doxygen package from http://www.doxygen.org
and the Graphviz package from http://www.research.att.com/sw/tools/graphviz.
After installing these two packages you can do 'make srcdoc' and then use your
HTML browser to read srcdoc/html/index.html.