mirror of
https://github.com/vdr-projects/vdr.git
synced 2025-03-01 10:50:46 +00:00
VDR developer version 2.3.1 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.2.0-2.3.1.diff MD5 checksums: 391c2ed60e2f7d24563fe3ed5854bc4f vdr-2.3.1.tar.bz2 983fd4bad7d19cd98301d54173107129 vdr-2.2.0-2.3.1.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. *** PLEASE BE VERY CAREFUL WHEN USING THIS DEVELOPER VERSION, ESPECIALLY *** IF YOU ENABLE THE NEW SVDRP PEERING! KEEP BACKUPS OF ALL YOUR TIMERS *** AND OBSERVE VERY CLOSELY WHETHER EVERYTHING WORKS AS EXPECTED. THIS *** VERSION INTRODUCES SOME MAJOR CHANGES IN HANDLING GLOBAL LISTS AND *** LOCKING, SO ANYTHING CAN HAPPEN! YOU HAVE BEEN WARNED! The main focus of this developer version is on the new locking mechanism for global lists, and the ability to handle remote timers. Any plugins that access the global lists of timers, channels, schedules or recordings, will need to be adjusted (see below for details). Please do initial tests with plain vanilla VDR and just the output plugin you need. Known bugs/problems: - After deleting the last recording in a sub folder, the cursor may not be positioned correctly. - Instant recordings and pausing live video don't (yet) use the default SVDRP host for recording. From the HISTORY file: - The new function cOsd::MaxPixmapSize() can be called to determine the maximum size a cPixmap may have on the current OSD. The 'osddemo' example has been modified accordingly. Plugin authors may want to use this function in case they use pixmaps that are larger than the full OSD size. The default implementation sets this limit to 2048x2048 pixel. - The Setup/CAM menu now displays which device an individual CAM is currently assigned to (suggested by Frank Neumann). - Added detection of 24fps (thanks to Thomas Reufer). - Added a note about the VDR User Counter and VDR's facebook page to the README file. - The dvbhddevice plugin is no longer part of the VDR source archive. You can get the latest version of this plugin from the author's repository at https://bitbucket.org/powARman/dvbhddevice. - The dvbsddevice and rcu plugins are no longer part of the VDR source archive. You can get the latest versions of these plugins from ftp://ftp.tvdr.de/vdr/Plugins. - Added a section about Output Devices to the INSTALL file. - Fixed setting the source value of newly created channels, in case the NIT is received from a different, but very close satellite position (reported by Daniel Ribeiro). The code for handling different NITs has been removed from nit.c, because according to the DVB standard table id 0x40 carries only the NIT of the actual network. - Added some comment to cPixmap about the relation between OSD, ViewPort and DrawPort (suggested by Thomas Reufer). - Improved syncing on sections when parsing the NIT and SDT. - Fixed scaling subtitles (their areas could sometimes extend outside the actual OSD). - Reduced the priority of the "video directory scanner" thread (suggested by Thomas Reufer) and checking cIoThrottle::Engaged() when it is running. - The script that gets called for recordings is now also called right before a recording is edited, with the first parameter being "editing" (suggested by Dieter Ferdinand). - The new setup option "OSD/Default sort mode for recordings" can be used to define how recordings shall be sorted by default (either by time or by name, with "by time" being the default). If a particular sort mode has been selected for a folder by pressing '0', the default no longer applies to that folder. Repeating timers no longer write a ".sort" file into a recordings folder to have the recordings sorted by time. - The command line option -D now accepts the value '-' (as in -D-), which prevents VDR from using any DVB devices (suggested by Dietmar Spingler). - The -V and -h options now list the plugins in alphabetical order (suggested by Dietmar Spingler). - Fixed a compiler warning in font.c. - Commented out the line #define DEPRECATED_VIDEOSYSTEM in device.h. If a plugin doesn't compile with this version of VDR, you can uncomment this line as a quick workaround. In the long run the plugin will need to be adapted. - The function cOsd::GetBitmap() is now 'protected'. If a plugin doesn't compile with this version of VDR, you can uncomment the line //#define DEPRECATED_GETBITMAP in osd.h as a quick workaround. In the long run the plugin will need to be adapted. - The -u option now also accepts a numerical user id (suggested by Derek Kelly). - The SVDRP port now accepts multiple concurrent connections. You can now keep an SVDRP connection open as long as you wish, without preventing others from connecting. Note, though, that SVDRP connections still get closed automatically if there has been no activity for 300 seconds (configurable via "Setup/Miscellaneous/SVDRP timeout (s)"). - The SVDRP log messages have been unified and now always contain the IP and port number of the remote host. - SVDRP connections are now handled in a separate "SVDRP server handler" thread, which makes them more responsive. Note that there is only one thread that handles all concurrent SVDRP connections. That way each SVDRP command is guaranteed to be processed separately, without interfering with any other SVDRP commands that might be issued at the same time. Plugins that implement SVDRP commands may need to take care of proper locking if the commands access global data. - VDR now sends out a broadcast to port 6419/udp, which was assigned to 'svdrp-disc' by the IANA. VDRs listening on that port will automatically initiate an SVDRP connection to the broadcasting VDR, and in turn send out a broadcast to make other VDRs connect to them. That way all VDRs within the local network will have permanent "peer-to-peer" SVDRP connections between each other. The configuration in the svdrphosts.conf file is taken into account when considering whether or not to respond to an SVDRP discover broadcast. - The new SVDRP command PING is used by automatically established peer-to-peer connections to keep them alive. - The new function GetSVDRPServerNames() can be used to get a list of all VDRs this VDR is connected to via SVDRP. - The new function ExecSVDRPCommand() can be used to execute an SVDRP command on one of the servers this VDR is connected to, and retrieve the result. The helper functions SVDRPCode() and SVDRPValue() can be used to easily access the codes and values returned by ExecSVDRPCommand(). - The cTimer class now has a new member named 'remote', which holds the name of the remote server this timer will record on. If this is NULL, it is a local timer. - Timers from other VDRs that are connected to this VDR via SVDRP are now automatically fetched and stored in the global Timers list. In order for this to work, all of the channels used by timers on the remote VDR must also be defined on the local VDR (however, not necessarily in the same sequence). Automatic channel syncing will be implemented later. - The main menu of the LCARS skin now displays a small rectangle on the left side of a timer if this is a remote timer. The color of that rectangle changes if the timer is currently recording on the remote VDR. - Accessing the global Timers list now has to be protected by proper locking, because SVDRP commands are now executed in a separate thread. The introduction of this locking mechanism required the following changes: + The new classes cStateLock and cStateKey are used to implement locking with quick detection of state changes. + cConfig::cConfig() now has a parameter that indicates whether this list requires locking. + The global lists of Timers, Channels, Schedules and Recordings are no longer static variables. They are now pointers that need to be retrieved through a call to cTimers::GetTimersRead/Write(), cChannels::GetChannelsRead/Write(), cSchedules::GetSchedulesRead/Write() and cRecordings::GetRecordingsRead/Write(), respectively. + References from/to link channels are now removed in cChannels::Del() rather than cChannel::~cChannel(), to make sure the caller holds a proper lock. + cChannel::HasTimer() has been removed. This information is now retrieved via cSchedule::HasTimer(). + Several member functions of cChannel, cTimer, cMarks and cRecording have been made 'const', and some of them are now available as both 'const' and 'non-const' versions. + The cChannel::Set...() functions are now 'bool' and return true if they have actually changed any of the channels's members. + cChannels::SetModified() has been renamed to cChannels::SetModifiedByUser(). + cChannels::Modified() has been renamed to cChannels::ModifiedByUser(), and now has a 'State' parameter that allows the caller to see whether a channel has been modified since the last call to this function with the same State variable. + The macros CHANNELSMOD_NONE/_AUTO/_USER have been removed. + cMarks now requires locking via cStateKey. + cSortedTimers now requires a pointer to the list of timers. + cEvent::HasTimer() no longer scans the list of timers to check whether an event is referenced by a timer, but rather keeps score of how many timers reference it. This was necessary in order to avoid having to lock the list of timers from within a cEvent. + The new class cListGarbageCollector is used to temporary store any objects deleted from cLists that require locking. This allows pointers to such objects to be dereferenced even if the objects are no longer part of the list. + cListBase::Contains() can be used to check whether a particular object is still contained in that list. + Outdated events are no longer "phased out", but rather deleted right away and thus taken care of by the new "garbage collector" of the list. + Deleted cRecording objects are no longer kept in a list of "vanished" recordings, but are rather taken care of by the new "garbage collector" of the list. + cSchedules::ClearAll() has been removed. The functionality is now implemented directly in cSVDRPServer::CmdCLRE(). + tEventID has been changed to u_int16_t in order to make room for the new member numTimers in cEvent. + cSchedule now has a member Modified(), which can be used with a State variable to quickly determine whether this schedule has been modified since the last call to this function with the same State variable. + cSchedulesLock has been removed. Locking the list of schedules is now done via the cList's new locking mechanism. + The 'OnlyRunningStatus' parameters in cEpgHandler::BeginSegmentTransfer() and cEpgHandler::EndSegmentTransfer() are now obsolete. They are still present in the interface for backward compatibility, but may be removed in a future version. Their value is always 'false'. + The constant tcMod is no longer used in cStatus::TimerChange(). The definition is still there for backward compatibility. Plugins that access the global lists of Timers, Channels, Recordings or Schedules will need to be adapted as follows: + Instead of directly accessing the global variables Timers, Channels or Recordings, they need to set up a cStateKey variable and call the proper getter function, as in cStateKey StateKey; if (const cTimers *Timers = cTimers::GetTimersRead(StateKey)) { // access the timers StateKey.Remove(); } and cStateKey StateKey; if (cTimers *Timers = cTimers::GetTimersWrite(StateKey)) { // access the timers StateKey.Remove(); } See timers.h, thread.h and tools.h for details on this new locking mechanism. + There are convenience macros for easily accessing these lists without having to explicitly set up a cStateKey and calling its Remove() function. These macros have the form LOCK_*_READ/WRITE (with '*' being TIMERS, CHANNELS, SCHEDULES or RECORDINGS). Simply put such a macro before the point where you need to access the respective list, and there will be a pointer named Timers, Channels, Schedules or Recordings, respectively, which is valid until the end of the current block. + If a plugin needs to access several of the global lists in parallel, locking must always be done in the sequence Timers, Channels, Recordings, Schedules. This is necessary to make sure that different threads that need to lock several lists at the same time don't end up in a deadlock. + Some pointer variables may need to be made 'const'. The compiler will tell you about these. - cSectionSyncer has been improved to better handle missed sections. - Added a missing initialization of 'seen' in cChannel's copy constructor. - Background modifications of channels, timers and events are now displayed immediately in the corresponding menus. - cEIT now checks the version of the tables before doing any processing, which saves a lot of locking and processing. - If a timer is newly created with the Red button in the Schedule menu, and the timer is presented to the user in the "Edit timer" menu because it will start immediately, it now *must* be confirmed with "Ok" to set the timer. Otherwise the timer will not be created. - Recordings and deleted recordings are now scanned in a single thread. - The new SVDRP command POLL is used by automatically established peer-to-peer connections to trigger fetching remote timers. - You can now set DumpSVDRPDataTransfer in svdrp.c to true to have all SVDRP communication printed to the console for debugging. - Added a missing 'const' to cReceiver::Receive(), to protect the given Data from being modified. - The SVDRP commands that deal with timers (DELT, LSTT, MODT, NEWT, NEXT and UPDT) as well as any log messages that refer to timers, now use a unique id for each timer, which remains valid as long as this instance of VDR is running. This means that timers are no longer continuously numbered from 1 to N in LSTT. There may be gaps in the sequence, in case timers have been deleted. - The Timers menu now displays the name of the remote VDR in front of the timer's file name, if this is a remote timer. - The new options "Setup/Miscellaneous/SVDRP peering", ".../SVDRP host name" and ".../SVDRP default host" can be used to configure automatic peering between VDRs in the same network. Peering is disabled by default and can be enabled by setting "SVDRP peering" to "yes". - The function cTimer::ToText() no longer returns a newline character at the end of the string. The newline is now added by the caller as necessary. This was changed because cTimer::ToText() is now also needed in a context where the terminating newline can't be used. Consequently, cChannel::ToText() and cMark::ToText() have been modified accordingly. - All timer related response strings from SVDRP commands now use the channel ID instead of channel numbers. - The "Edit timer" menu now has a new parameter "Record on", which can be used to select the VDR on which this timer shall record. Timers can be freely moved between connected VDRs by simply selecting the desired machine in this field. - The SVDRP command DELT no longer checks whether the timer that shall be deleted is currently recording. - The character 0x0D is now stripped from EPG texts (reported by Janne Pänkälä). - The EPG scanner no longer moves the dish if there is a positioner. - The 'newplugin' script now creates the 'po' subdirectory for translations (thanks to Thomas Reufer). - Skins can now implement cSkinDisplayMenu::MenuOrientation() to display horizontal menus (thanks to Stefan Braun). - Fixed a possible stack overflow in cListBase::Sort() (thanks to Oliver Endriss). - Changed the description of the --chartab option in the INSTALL file to refer to "DVB SI table strings" instead of "EPG data". - The width and height of the OSD are now limited to the actual maximum dimensions of the output device, taking into account the top and left offset. - The new setup option "Recording/Record key handling" can be used to define what happens if the Record key on the remote control is pressed during live tv (suggested by Dietmar Spingler). - Empty adaptation field TS packets are now skipped when recording (thanks to Christopher Reimer, based on the "AFFcleaner" by Stefan Pöschel).
940 lines
36 KiB
Groff
940 lines
36 KiB
Groff
'\" t
|
|
.\" ** The above line should force tbl to be a preprocessor **
|
|
.\" Man page for vdr file formats
|
|
.\"
|
|
.\" Copyright (C) 2013 Klaus Schmidinger
|
|
.\"
|
|
.\" You may distribute under the terms of the GNU General Public
|
|
.\" License as specified in the file COPYING that comes with the
|
|
.\" vdr distribution.
|
|
.\"
|
|
.\" $Id: vdr.5 4.0 2015/02/17 13:43:53 kls Exp $
|
|
.\"
|
|
.TH vdr 5 "19 Feb 2015" "2.2" "Video Disk Recorder Files"
|
|
.SH NAME
|
|
vdr_files \- the Video Disk Recorder Files
|
|
.SH DESCRIPTION
|
|
This page describes the formats of the various files \fBvdr\fR uses to
|
|
store configuration data and recordings.
|
|
.SH SYNTAX
|
|
.SS CHANNELS
|
|
The file \fIchannels.conf\fR contains the channel configuration.
|
|
Each line defines either a \fBgroup delimiter\fR or a \fBchannel\fR.
|
|
|
|
A \fBgroup delimiter\fR is a line starting with a ':' as the very first
|
|
character, followed by arbitrary text. Example:
|
|
|
|
\fB:First group\fR
|
|
|
|
Group delimiters may also be used to specify the number of the next channel.
|
|
To do this, the character '@' and a number must immediately follow the ':',
|
|
as in
|
|
|
|
\fB:@201 First group\fR
|
|
|
|
The given number must be larger than the number of any previous channel
|
|
(otherwise it is silently ignored).
|
|
|
|
A group delimiter can also be used to just set the next channel's number,
|
|
without an explicit delimiter text, as in
|
|
|
|
\fB:@201\fR
|
|
|
|
Such a delimiter will not appear in the Channels menu.
|
|
|
|
A \fBchannel definition\fR is a line with channel data, where the fields
|
|
are separated by ':' characters. Example:
|
|
|
|
.TS
|
|
tab (@);
|
|
l.
|
|
\fBRTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0\fR
|
|
.TE
|
|
|
|
The line number of a channel definition (not counting group separators,
|
|
and based on a possible previous '@...' parameter)
|
|
defines the channel's number in OSD menus and the \fItimers.conf\fR file.
|
|
|
|
The fields in a channel definition have the following meaning (from left
|
|
to right):
|
|
.TP
|
|
.B Name
|
|
The channel's name (if the name originally contains a ':' character
|
|
it has to be replaced by '|').
|
|
Some TV stations provide a way of deriving a "short name" from the
|
|
channel name, which can be used in situations where there is not
|
|
much space for displaying a long name. If a short name is available
|
|
for this channel, it follows the full name and is delimited by a comma,
|
|
as in
|
|
|
|
\fBRTL Television,RTL:...\fR
|
|
|
|
If the short name itself would contain a comma, it is replaced with a '.'.
|
|
Note that some long channel names may contain a comma, so the delimiting comma
|
|
is always the rightmost one.
|
|
|
|
If present, the name of the service provider or "bouquet" is appended
|
|
to the channel name, separated by a semicolon, as in
|
|
|
|
\fBRTL Television,RTL;RTL World:...\fR
|
|
.TP
|
|
.B Frequency
|
|
The transponder frequency (as an integer). For DVB-S this value is in MHz. For DVB-C
|
|
and DVB-T it can be given either in MHz, kHz or Hz (the actual value given will be
|
|
multiplied by 1000 until it is larger than 1000000).
|
|
.TP
|
|
.B Parameters
|
|
Various parameters, depending on whether this is a DVB-S, DVB-C or DVB-T channel.
|
|
Each parameter consist of a key character, followed by an integer number that
|
|
represents the actual setting of that parameter. The valid key characters, their
|
|
meaning (and allowed values) are
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fBB\fR@Bandwidth (1712, 5, 6, 7, 8, 10)
|
|
\fBC\fR@Code rate high priority (0, 12, 23, 34, 35, 45, 56, 67, 78, 89, 910)
|
|
\fBD\fR@coDe rate low priority (0, 12, 23, 34, 35, 45, 56, 67, 78, 89, 910)
|
|
\fBG\fR@Guard interval (4, 8, 16, 32, 128, 19128, 19256)
|
|
\fBH\fR@Horizontal polarization
|
|
\fBI\fR@Inversion (0, 1)
|
|
\fBL\fR@Left circular polarization
|
|
\fBM\fR@Modulation (2, 5, 6, 7, 10, 11, 12, 16, 32, 64, 128, 256, 999)
|
|
\fBN\fR@pilot mode (0, 1, 999)
|
|
\fBO\fR@rollOff (0, 20, 25, 35)
|
|
\fBP\fR@stream id (0-255)
|
|
\fBQ\fR@t2 system id (0-65535)
|
|
\fBR\fR@Right circular polarization
|
|
\fBS\fR@delivery System (0, 1)
|
|
\fBT\fR@Transmission mode (1, 2, 4, 8, 16, 32)
|
|
\fBV\fR@Vertical polarization
|
|
\fBX\fR@siso/miso mode (0, 1)
|
|
\fBY\fR@hierarchY (0, 1, 2, 4)
|
|
.TE
|
|
|
|
\fBBandwidth:\fR The bandwidth of the channel in MHz (1712 in kHz): (DVB-T/DVB-T2 only).
|
|
|
|
\fBCode rate high priority:\fR Forward Error Correction (FEC) of the high priority stream (DVB-T/DVB-T2).
|
|
For DVB-S/DVB-S2 this parameter specifies the inner FEC scheme.
|
|
12 = 1/2, 23 = 2/3, 34 = 3/4, ...
|
|
|
|
\fBCode rate low priority:\fR Forward Error Correction (FEC) of the low priority stream (DVB-T/DVB-T2 only).
|
|
If no hierarchy is used, set to 0.
|
|
|
|
\fBGuard interval:\fR The guard interval value (DVB-T only): 4 = 1/4, 8 = 1/8, 16 = 1/16, 32 = 1/32, 128 = 1/128, 19128 = 19/128, 19256 = 19/256.
|
|
|
|
\fBInversion:\fR Specifies whether the DVB frontend needs spectral inversion (DVB-T and DVB-C only). This is frontend specific, if in doubt, omit.
|
|
|
|
\fBModulation:\fR Specifies the modulation/constellation of the channel as follows:
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fB2\fR@QPSK (DVB-S, DVB-S2, DVB-T, DVB-T2, ISDB-T)
|
|
\fB5\fR@8PSK (DVB-S, DVB-S2)
|
|
\fB6\fR@16APSK (DVB-S2)
|
|
\fB7\fR@32APSK (DVB-S2)
|
|
\fB10\fR@VSB8 (ATSC aerial)
|
|
\fB11\fR@VSB16 (ATSC aerial)
|
|
\fB12\fR@DQPSK (ISDB-T)
|
|
\fB16\fR@QAM16 (DVB-T, DVB-T2, ISDB-T)
|
|
\fB32\fR@QAM32
|
|
\fB64\fR@QAM64 (DVB-C, DVB-T, DVB-T2, ISDB-T)
|
|
\fB128\fR@QAM128 (DVB-C)
|
|
\fB256\fR@QAM256 (DVB-C, DVB-T2)
|
|
.TE
|
|
|
|
\fBPilot mode:\fR The pilot mode (0 = "off", 1 = "on", 999 = "auto") for DVB-S2 multiplex (DVB-S2 only).
|
|
|
|
\fBRolloff:\fR The Nyquist filter rolloff factor for DVB-S (\fB35\fR) and DVB-S2 (\fB35\fR, 25, 20),
|
|
35 = 0.35, 25 = 0.25, 20 = 0.20, DVB-S/DVB-S2 default value is 0.35
|
|
|
|
\fBStream id:\fR Input Stream Identifier (ISI) (\fB0\fR-255) for DVB-S2 multiplex or
|
|
Physical Layer Pipe (PLP) id (\fB0\fR-255) for DVB-T2 multiplex (DVB-S2/DVB-T2 only,
|
|
with devices that support "multi streaming").
|
|
|
|
\fBT2 System id:\fR Unique identifier (\fB0\fR-65535) of T2 system within the DVB network (DVB-T2).
|
|
|
|
\fBTransmission mode:\fR Number of DVB-T OFDM carriers, 32 = 32k, 16 = 16k, 8 = 8k, 4 = 4k, 2 = 2k, 1 = 1k. If in doubt, try 8k.
|
|
|
|
\fBSISO/MISO mode:\fR Specifies the Single-Input/Multiple-Input Single-Output mode (\fB0\fR = SISO, 1 = MISO) (DVB-T2).
|
|
|
|
\fBHierarchy:\fR If set to 1, this transponder uses two streams, high priority and low priority.
|
|
If in doubt, try 0 (off). (DVB-T/DVB-T2 only).
|
|
|
|
\fBDelivery System:\fR The delivery system (0 = "first generation" (DVB-S/DVB-T), 1 = "second generation" (DVB-S2/DVB-T2).
|
|
|
|
\fBPolarization:\fR Satellite antenna polarization.
|
|
H = horizontal, V = vertical, R = circular right, L = circular left.
|
|
|
|
The polarization parameters have no integer numbers following them. This is for
|
|
compatibility with files from older versions and also to keep the DVB-S entries
|
|
as simple as possible.
|
|
|
|
The special value \fB999\fR is used for "automatic", which means the driver
|
|
will automatically determine the proper value (if possible).
|
|
|
|
An example of a parameter field for a DVB-T channel might look like this:
|
|
\fBB8C23D12G8M16T8Y0S0\fR
|
|
|
|
An example of a parameter field for a DVB-T2 channel might look like this:
|
|
\fBB8C23D12G8M16T8Y0P0S1\fR
|
|
|
|
An example of a parameter field for a DVB-C channel might look like this:
|
|
\fBC0M64\fR
|
|
|
|
An example of a parameter field for a DVB-S channel might look like this:
|
|
\fBHC56M2O35S0\fR
|
|
|
|
An example of a parameter field for a DVB-S2 channel might look like this:
|
|
\fBHC910M2O35S1\fR
|
|
|
|
Plugins that implement devices that need their own set of parameters may
|
|
store those in the parameters string in arbitrary format (not necessarily
|
|
the "character/number" format listed above). The only condition is that
|
|
the string may not contain colons (':') or newline characters.
|
|
.TP
|
|
.B Source
|
|
The signal source of this channel, as defined in the file \fIsources.conf\fR.
|
|
.TP
|
|
.B Srate
|
|
The symbol rate of this channel (DVB-S and DVB-C only).
|
|
.TP
|
|
.B VPID
|
|
The video PID (set to '0' for radio channels).
|
|
If this channel uses a separate PCR PID, it follows the VPID, separated by a
|
|
plus sign, as in
|
|
|
|
.B ...:164+17:...
|
|
|
|
If this channel has a video mode other than 0, the mode
|
|
follows the pids, separated by an '=' sign, as in
|
|
|
|
.B ...:164+17=27:...
|
|
.TP
|
|
.B APID
|
|
The audio PID (either one number, or several, separated by commas).
|
|
If this channel also carries Dolby Digital sound, the Dolby PIDs follow
|
|
the audio PIDs, separated by a semicolon, as in
|
|
|
|
.B ...:101,102;103,104:...
|
|
|
|
If certain audio PIDs broadcast in specific languages, the language
|
|
codes for these can be appended to the individual audio or Dolby PID, separated
|
|
by an '=' sign, as in
|
|
|
|
.B ...:101=deu,102=eng;103=deu,104=eng:...
|
|
|
|
Some channels broadcast two different languages in the two stereo channels, which
|
|
can be indicated by adding a second language code, delimited by a '+' sign, as in
|
|
|
|
.B ...:101=deu,102=eng+spa;103=deu,104=eng:...
|
|
|
|
The audio type is appended with a separating '@' character, as in
|
|
|
|
.B ...:101=deu@4,102=eng+spa@4,105=@4:...
|
|
|
|
Note that if there is no language code, there still is the separating '='
|
|
if there is an audio type.
|
|
|
|
.TP
|
|
.B TPID
|
|
The teletext PID.
|
|
If this channel also carries DVB subtitles, the DVB subtitling PIDs follow the
|
|
teletext PID, separated by a semicolon, as in
|
|
|
|
.B ...:201;2001,2002:...
|
|
|
|
If certain subtitling PIDs broadcast in specific languages, the language
|
|
codes for these can be appended to the individual subtitling PID, separated
|
|
by an '=' sign, as in
|
|
|
|
.B ...:201;2001=deu,2002=eng:...
|
|
|
|
.TP
|
|
.B Conditional access
|
|
A hexadecimal integer defining how this channel can be accessed:
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fB0000\fR@Free To Air
|
|
\fB0001...000F\fR@explicitly requires the device with the given number
|
|
\fB0010...00FF\fR@reserved for user defined assignments
|
|
\fB0100...FFFF\fR@specific decryption methods as broadcast in the data stream\fR
|
|
.TE
|
|
Values in the range 0001...00FF will not be overwritten, all other values
|
|
will be automatically replaced by the actual CA system identifiers received
|
|
from the data stream. If there is more than one CA system id broadcast, they
|
|
will be separated by commas, as in
|
|
|
|
.B ...:1702,1722,1801:...
|
|
|
|
The values are in hex because that's the way they are defined in the "ETR 162"
|
|
document. Leading zeros may be omitted.
|
|
.TP
|
|
.B SID
|
|
The Service ID of this channel.
|
|
.TP
|
|
.B NID
|
|
The Network ID of this channel.
|
|
.TP
|
|
.B TID
|
|
The Transport stream ID of this channel.
|
|
.TP
|
|
.B RID
|
|
The Radio ID of this channel (typically 0, may be used to distinguish channels where
|
|
NID, TID and SID are all equal).
|
|
.PP
|
|
A particular channel can be uniquely identified by its \fBchannel\ ID\fR,
|
|
which is a string that looks like this:
|
|
|
|
\fBS19.2E\-1\-1089\-12003\-0\fR
|
|
|
|
The components of this string are the \fBSource\fR (S19.2E), \fBNID\fR
|
|
(1), \fBTID\fR (1089), \fBSID\fR (12003) and \fBRID\fR (0) as defined above.
|
|
The last part can be omitted if it is \fB0\fR,
|
|
so the above example could also be written as S19.2E\-1\-1089\-12003).
|
|
.br
|
|
The \fBchannel\ ID\fR is used in the \fItimers.conf\fR and \fIepg.data\fR
|
|
files to properly identify the channels.
|
|
|
|
If a channel has both \fBNID\fR and \fBTID\fR set to 0, the \fBchannel\ ID\fR
|
|
will use the \fBFrequency\fR instead of the \fBTID\fR. For satellite channels
|
|
an additional offset of 100000, 200000, 300000 or 400000 is added to that
|
|
number, depending on the \fBPolarization\fR (\fBH\fR, \fBV\fR, \fBL\fR or \fBR\fR,
|
|
respectively). This is necessary because on some satellites the same frequency is
|
|
used for two different transponders, with opposite polarization.
|
|
.SS TIMERS
|
|
The file \fItimers.conf\fR contains the timer setup.
|
|
Each line contains one timer definition, with individual fields
|
|
separated by ':' characters. Example:
|
|
|
|
\fB1:10:\-T\-\-\-\-\-:2058:2150:50:5:Quarks & Co:\fR
|
|
|
|
The fields in a timer definition have the following meaning (from left
|
|
to right):
|
|
.TP
|
|
.B Flags
|
|
The individual bits in this field have the following meaning:
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fB1\fR@the timer is active (and will record if it hits)
|
|
\fB2\fR@this is an instant recording timer
|
|
\fB4\fR@this timer uses VPS
|
|
\fB8\fR@this timer is currently recording (may only be up-to-date with SVDRP)
|
|
.TE
|
|
|
|
All other bits are reserved for future use.
|
|
.TP
|
|
.B Channel
|
|
The channel to record from. This is either the channel number as shown in the
|
|
on-screen menus, or a complete channel ID. When reading \fItimers.conf\fR
|
|
any channel numbers will be mapped to the respective channel ids and when
|
|
the file is written again, there will only be channel ids. Channel numbers
|
|
are accepted as input in order to allow easier creation of timers when
|
|
manually editing \fItimers.conf\fR. Also, when timers are listed via SVDRP
|
|
commands, the channels are given as numbers.
|
|
.TP
|
|
.B Day
|
|
The day when this timer shall record.
|
|
|
|
If this is a `single-shot' timer, this is the date on which this
|
|
timer shall record, given in ISO notation (\fBYYYY-MM-DD\fR), as in:
|
|
|
|
.B 2005-03-19
|
|
|
|
For compatibility with earlier versions of VDR this may also be just the day of month
|
|
on which this timer shall record (must be in the range \fB1...31\fR).
|
|
|
|
In case of a `repeating' timer this is a string consisting of exactly seven
|
|
characters, where each character position corresponds to one day of the week
|
|
(with Monday being the first day). The character '\-' at a certain position
|
|
means that the timer shall not record on that day. Any other character will
|
|
cause the timer to record on that day. Example:
|
|
|
|
.B MTWTF\-\-
|
|
|
|
will define a timer that records on Monday through Friday and does not record
|
|
on weekends.
|
|
Note that only letters may be used here, no digits.
|
|
For compatibility with timers created with earlier versions of VDR,
|
|
the same result could be achieved with \fBABCDE\-\-\fR (which was
|
|
used to allow setting the days with language specific characters).
|
|
Since version 1.5.3 VDR can use UTF-8 characters to present data to
|
|
the user, but the weekday encoding in the \fItimers.conf\fR file
|
|
always uses single byte characters.
|
|
|
|
The day definition of a `repeating' timer may be followed by the date when that
|
|
timer shall hit for the first time. The format for this is \fB@YYYY\-MM\-DD\fR,
|
|
so a complete definition could look like this:
|
|
|
|
\fBMTWTF\-\-@2002\-02\-18\fR
|
|
|
|
which would implement a timer that records Monday through Friday, and will hit
|
|
for the first time on or after February 18, 2002.
|
|
This \fBfirst day\fR feature can be used to disable a repeating timer for a couple
|
|
of days, or for instance to define a new Mon...Fri timer on Wednesday, which
|
|
actually starts "Monday next week". The \fBfirst day\fR date given need not be
|
|
that of a day when the timer would actually hit.
|
|
.TP
|
|
.B Start
|
|
A four digit integer defining when this timer shall \fBstart\fR recording.
|
|
The format is \fBhhmm\fR, so \fB1430\fR would mean "half past two" in the
|
|
afternoon.
|
|
.TP
|
|
.B Stop
|
|
A four digit integer defining when this timer shall \fBstop\fR recording.
|
|
The format is the same as for the \fBstart\fR time.
|
|
.TP
|
|
.B Priority
|
|
An integer in the range \fB0...99\fR, defining the \fBpriority\fR
|
|
of this timer and of recordings created by this timer.
|
|
\fB0\fR represents the lowest value, \fB99\fR the highest.
|
|
The priority is used to decide which timer shall be
|
|
started in case there are two or more timers with the exact same
|
|
\fBstart\fR time. The first timer in the list with the highest priority
|
|
will be used.
|
|
|
|
This value is also stored with the recording and is
|
|
later used to decide which recording to remove from disk in order
|
|
to free space for a new recording. If the disk runs full and a new
|
|
recording needs more space, an existing recording with the lowest
|
|
priority (and which has exceeded its guaranteed \fBlifetime\fR) will be
|
|
removed.
|
|
|
|
If all available DVB cards are currently occupied, a
|
|
timer with a higher priority will interrupt the timer with the
|
|
lowest priority in order to start recording.
|
|
.TP
|
|
.B Lifetime
|
|
The \fBguaranteed lifetime\fR (in days) of a recording created by this timer.
|
|
\fB0\fR means that this recording may be automatically deleted at any time
|
|
by a new recording with higher priority. \fB99\fR means that this recording
|
|
will never be automatically deleted. Any number in the range \fB1...98\fR
|
|
means that this recording may not be automatically deleted in favour of a
|
|
new recording, until the given number of days since the \fBstart\fR time of
|
|
the recording has passed by.
|
|
.TP
|
|
.B File
|
|
The \fBfile name\fR this timer will give to a recording.
|
|
If the name contains any ':' characters, these have to be replaced by '|'.
|
|
If the name shall contain subdirectories, these have to be delimited by '~'
|
|
(since the '/' character may be part of a regular programme name).
|
|
|
|
The special keywords \fBTITLE\fR and \fBEPISODE\fR, if present, will be replaced
|
|
by the title and episode information from the EPG data at the time of
|
|
recording (if that data is available). If at the time of recording either
|
|
of these cannot be determined, \fBTITLE\fR will default to the channel name, and
|
|
\fBEPISODE\fR will default to a blank.
|
|
.TP
|
|
.B Auxiliary data
|
|
An arbitrary string that can be used by external applications to store any
|
|
kind of data related to this timer. The string must not contain any newline
|
|
characters. If this field is not empty, its contents will be written into the
|
|
\fIinfo\fR file of the recording with the '@' tag.
|
|
.SS SOURCES
|
|
The file \fIsources.conf\fR defines the codes to be used in the \fBSource\fR field
|
|
of channels in \fIchannels.conf\fR and assigns descriptive texts to them.
|
|
Example:
|
|
|
|
\fBS19.2E Astra 1\fR
|
|
|
|
Anything after (and including) a '#' character is comment.
|
|
|
|
The first character of the \fBcode\fR must be one of
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fBA\fR@ATSC
|
|
\fBC\fR@Cable
|
|
\fBS\fR@Satellite
|
|
\fBT\fR@Terrestrial
|
|
.TE
|
|
|
|
and is followed by further data pertaining to that particular source. In case of
|
|
\fBS\fRatellite this is the orbital position in degrees, followed by \fBE\fR for
|
|
east or \fBW\fR for west.
|
|
Plugins may define additional sources, using other characters in the range 'A'...'Z'.
|
|
.SS DISEQC
|
|
The file \fIdiseqc.conf\fR defines the \fBDiSEqC\fR control sequences to be sent
|
|
to the DVB-S card in order to access a given satellite position and/or band.
|
|
Example:
|
|
|
|
\fBS19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t\fR
|
|
|
|
Anything after (and including) a '#' character is comment.
|
|
|
|
The first word in a parameter line must be one of the codes defined in the
|
|
file \fIsources.conf\fR and tells which satellite this line applies to.
|
|
|
|
Following is the "switch frequency" of the LNB (slof), which is the transponder
|
|
frequency up to which this entry shall be used; the first entry with an slof greater
|
|
than the actual transponder frequency will be used. Typically there is only one slof
|
|
per LNB, but the syntax allows any number of frequency ranges to be defined.
|
|
Note that there should be a last entry with the value \fB99999\fR for each satellite,
|
|
which covers the upper frequency range.
|
|
|
|
The third parameter defines the polarization to which this entry applies. It can
|
|
be either \fBH\fR for horizontal, \fBV\fR for vertical, \fBL\fR for circular left
|
|
or \fBR\fR for circular right.
|
|
|
|
The fourth parameter specifies the "local oscillator frequency" (lof) of the LNB
|
|
to use for the given frequency range. This number will be subtracted from the
|
|
actual transponder frequency when tuning to the channel.
|
|
|
|
The rest of the line holds the actual sequence of DiSEqC actions to be taken.
|
|
The code letters used here are
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fBt\fR@22kHz tone off
|
|
\fBT\fR@22kHz tone on
|
|
\fBv\fR@voltage low (13V)
|
|
\fBV\fR@voltage high (18V)
|
|
\fBA\fR@mini A
|
|
\fBB\fR@mini B
|
|
\fBPn\fR@use positioner to move dish to satellite position n (or to the satellite's orbital position, if no position number is given)
|
|
\fBSn\fR@Satellite channel routing code sequence for bank n follows
|
|
\fBWnn\fR@wait nn milliseconds (nn may be any positive integer number)
|
|
\fB[xx ...]\fR@hex code sequence (max. 6)
|
|
.TE
|
|
There can be any number of actions in a line, including none at all - in which case
|
|
the entry would be used only to set the LOF to use for the given frequency range
|
|
and polarization.
|
|
|
|
By default it is assumed that every DVB-S device can receive every satellite.
|
|
If this is not the case in a particular setup, lines of the form
|
|
|
|
\fB1 2 4:\fR
|
|
|
|
may be inserted in the \fIdiseqc.conf\fR file, defining the devices that are able
|
|
to receive the satellites following thereafter. In this case, only the devices
|
|
1, 2 and 4 would be able to receive any satellites following this line and up
|
|
to the next such line, or the end of the file. Devices may be listed more than
|
|
once.
|
|
.SS SATELLITE CHANNEL ROUTING (SCR)
|
|
The file \fIscr.conf\fR contains the channel definitions of the SCR device in use.
|
|
The format is
|
|
|
|
channel frequency [pin]
|
|
|
|
where channel is the SCR device's channel index (0-7), frequency is the user band
|
|
frequency of the given channel, and pin is an optional pin number (0-255). The
|
|
actual values are device specific and can be found in the SCR device's manual.
|
|
|
|
Examples:
|
|
|
|
0 1284
|
|
.br
|
|
1 1400
|
|
.br
|
|
2 1516
|
|
.br
|
|
3 1632
|
|
.br
|
|
4 1748
|
|
.br
|
|
5 1864
|
|
.br
|
|
6 1980
|
|
.br
|
|
7 2096
|
|
|
|
By default it is assumed that the SCR configurations apply to all devices, and
|
|
each device will pick one. If you have several SCR sat cables connected to one
|
|
VDR machine, or if you want to explicitly assign the SCR channels to your devices,
|
|
lines of the form
|
|
|
|
\fB1 2 4:\fR
|
|
|
|
may be inserted in the \fIscr.conf\fR file, defining the devices that are allowed
|
|
to use the SCR channels thereafter. In this case, only the devices
|
|
1, 2 and 4 would be allowed to use the SCR channels following this line and up
|
|
to the next such line, or the end of the file. If a device is listed more than
|
|
once, only its first appearance counts.
|
|
.SS REMOTE CONTROL KEYS
|
|
The file \fIremote.conf\fR contains the key assignments for all remote control
|
|
units. Each line consists of one key assignment in the following format:
|
|
|
|
\fBname.key code\fR
|
|
|
|
where \fBname\fR is the name of the remote control (for instance KBD for the
|
|
PC keyboard, or LIRC for the
|
|
"Linux Infrared Remote Control"), \fBkey\fR is the name of the key that is
|
|
defined (like Up, Down, Menu etc.), and \fBcode\fR is a character string that
|
|
this remote control delivers when the given key is pressed.
|
|
.SS KEY MACROS
|
|
The file \fIkeymacros.conf\fR contains user defined macros that will be executed
|
|
whenever the given key is pressed. The format is
|
|
|
|
\fBmacrokey [@plugin] key1 key2 key3...\fR
|
|
|
|
where \fBmacrokey\fR is the key that shall initiate execution of this macro
|
|
and can be one of \fIUp\fR, \fIDown\fR, \fIOk\fR, \fIBack\fR, \fILeft\fR,
|
|
\fIRight\fR, \fIRed\fR, \fIGreen\fR, \fIYellow\fR, \fIBlue\fR, \fI0\fR...\fI9\fR
|
|
or \fIUser1\fR...\fIUser9\fR. The rest of the line consists of a set of
|
|
keys, which will be executed just as if they had been pressed in the given
|
|
sequence. The optional \fB@plugin\fR can be used to automatically select
|
|
the given plugin.
|
|
\fBplugin\fR is the name of the plugin, exactly as given in the \-P
|
|
option when starting VDR. There can be only one \fB@plugin\fR per key macro.
|
|
For instance
|
|
|
|
\fBUser1 @abc Down Down Ok\fR
|
|
|
|
would call the main menu function of the "abc" plugin and execute two "Down"
|
|
key presses, followed by "Ok".
|
|
.br
|
|
Note that the color keys will only execute their macro function
|
|
in "normal viewing" mode (i.e. when no other menu or player is active). The
|
|
\fIUser1\fR...\fIUser9\fR keys will always execute their macro function.
|
|
There may be up to 15 keys in such a key sequence.
|
|
.SS FOLDERS
|
|
The file \fIfolders.conf\fR contains the definitions of folders that can be used
|
|
in the "Edit timer" menu. Each line contains one folder definition. Leading whitespace
|
|
and everything after and including a '#' is ignored. A line ending with '{'
|
|
defines a sub folder (i.e. a folder that contains other folders), and a line
|
|
consisting of only '}' ends the definition of a sub folder.
|
|
|
|
Example:
|
|
|
|
Daily {
|
|
.br
|
|
News
|
|
.br
|
|
Soaps
|
|
.br
|
|
}
|
|
.br
|
|
Archive {
|
|
.br
|
|
Movies
|
|
.br
|
|
Sports
|
|
.br
|
|
Sci-Fi {
|
|
.br
|
|
Star Trek
|
|
.br
|
|
U.F.O.
|
|
.br
|
|
}
|
|
.br
|
|
}
|
|
.br
|
|
Comedy
|
|
.br
|
|
Science
|
|
|
|
Note that these folder definitions are only used to set the file name under which
|
|
a timer will store its recording. Changing these definitions in any way has no
|
|
effect on existing timers or recordings.
|
|
.SS COMMANDS
|
|
The file \fIcommands.conf\fR contains the definitions of commands that can
|
|
be executed from the \fBvdr\fR main menu's "Commands" option.
|
|
Each line contains one command definition in the following format:
|
|
|
|
\fBtitle : command\fR
|
|
|
|
where \fBtitle\fR is the string that will be displayed in the "Commands" menu,
|
|
and \fBcommand\fR is the actual command string that will be executed when this
|
|
option is selected. The delimiting ':' may be surrounded by any number of
|
|
white space characters. If \fBtitle\fR ends with the character '?', there will
|
|
be a confirmation prompt before actually executing the command. This can be
|
|
used for commands that might have serious results (like deleting files etc)
|
|
to make sure they are not executed inadvertently.
|
|
|
|
Everything following (and including) a '#' character is considered to be comment.
|
|
|
|
You can have nested layers of command menus by surrounding a sequence of
|
|
commands with '{'...'}' and giving it a title, as in
|
|
|
|
My Commands {
|
|
.br
|
|
First list {
|
|
Do something: some command
|
|
Do something else: another command
|
|
}
|
|
Second list {
|
|
Even more: yet another command
|
|
So much more: and yet another one
|
|
}
|
|
.br
|
|
}
|
|
|
|
Command lists can be nested to any depth.
|
|
|
|
By default the menu entries in the "Commands" menu will be numbered '1'...'9'
|
|
to make them selectable by pressing the corresponding number key. If you want
|
|
to use your own numbering scheme (maybe to skip certain numbers), just precede
|
|
the \fBtitle\fRs with the numbers of your choice. \fBvdr\fR will suppress its
|
|
automatic numbering if the first entry in \fIcommands.conf\fR starts with a
|
|
digit in the range '1'...'9', followed by a blank.
|
|
|
|
In order to avoid error messages to the console, every command should have
|
|
\fIstderr\fR redirected to \fIstdout\fR. Everything the command prints to
|
|
\fIstdout\fR will be displayed in a result window, with \fBtitle\fR as its title.
|
|
|
|
Examples:
|
|
|
|
Check for new mail?: /usr/local/bin/checkmail 2>&1
|
|
.br
|
|
CPU status: /usr/local/bin/cpustatus 2>&1
|
|
.br
|
|
Disk space: df \-h | grep '/video' | awk '{ print 100 \- $5 "% free"; }'
|
|
.br
|
|
Calendar: date;echo;cal
|
|
|
|
Note that the commands 'checkmail' and 'cpustatus' are only \fBexamples\fR!
|
|
Don't send emails to the author asking where to find these ;\-)
|
|
.br
|
|
The '?' at the end of the "Check for new mail?" entry will prompt the user
|
|
whether this command shall really be executed.
|
|
.SS RECORDING COMMANDS
|
|
The file \fIreccmds.conf\fR can be used to define commands that can be applied
|
|
to the currently highlighted recording in the "Recordings" menu. The syntax is
|
|
exactly the same as described for the file \fIcommands.conf\fR. When executing
|
|
a command, the directory name of the recording will be appended to the command
|
|
string, separated by a blank and enclosed in single quotes.
|
|
.SS SVDRP HOSTS
|
|
The file \fIsvdrphosts.conf\fR contains the IP numbers of all hosts that are
|
|
allowed to access the SVDRP port.
|
|
Each line contains one IP number in the format
|
|
|
|
\fBIP-Address[/Netmask]\fR
|
|
|
|
where \fBIP-Address\fR is the address of a host or a network in the usual dot
|
|
separated notation (as in 192.168.100.1). If the optional \fBNetmask\fR is given
|
|
only the given number of bits of \fBIP-Address\fR are taken into account. This
|
|
allows you to grant SVDRP access to all hosts of an entire network. \fBNetmask\fR
|
|
can be any integer from 1 to 32. The special value of 0 is only accepted if
|
|
the \fBIP-Address\fR is 0.0.0.0, because this will give access to any host
|
|
(\fBUSE THIS WITH CARE!\fR).
|
|
|
|
Everything following (and including) a '#' character is considered to be comment.
|
|
|
|
Examples:
|
|
|
|
127.0.0.1 # always accept localhost
|
|
.br
|
|
192.168.100.0/24 # any host on the local net
|
|
.br
|
|
204.152.189.113 # a specific host
|
|
.br
|
|
0.0.0.0/0 # any host on any net (\fBUSE WITH CARE!\fR)
|
|
.SS SETUP
|
|
The file \fIsetup.conf\fR contains the basic configuration options for \fBvdr\fR.
|
|
Each line contains one option in the format "Name = Value".
|
|
See the MANUAL file for a description of the available options.
|
|
.SS THEMES
|
|
The files \fIthemes/<skin>\-<theme>.theme\fR in the config directory contain the
|
|
color theme definitions for the various skins. In the actual file names \fI<skin>\fR
|
|
will be replaced by the name if the skin this theme belongs to, and \fI<theme>\fR
|
|
will be the name of this theme.
|
|
Each line in a theme file contains one option in the format "Name = Value".
|
|
Anything after (and including) a '#' character is comment.
|
|
|
|
The definitions in a theme file are either \fBcolors\fR or a \fBdescription\fR.
|
|
.br
|
|
\fBColors\fR are in the form
|
|
|
|
\fBclrTitle = FF123456\fR
|
|
|
|
where the name (clrTitle) is one of the names defined in the source code of
|
|
the \fBskin\fR that uses this theme, through the \fBTHEME_CLR()\fR macro.
|
|
The value (FF123456) is an eight digit hex number that consist of four bytes,
|
|
representing alpha (transparency), red, green and blue component of the color.
|
|
An alpha value of 00 means the color will be completely transparent, while FF
|
|
means it will be opaque. An RGB value of 000000 results in black, while FFFFFF
|
|
is white.
|
|
|
|
A \fBdescription\fR can be given as
|
|
|
|
\fBDescription = Shades of blue\fR
|
|
|
|
and will be used in the Setup/OSD menu to select a theme for a given skin.
|
|
The description should give the user an idea what this theme will be like
|
|
(for instance, in the given example it would use various shades of blue),
|
|
and shouldn't be too long to make sure it fits on the Setup screen.
|
|
The default description always should be given in English. If you want,
|
|
you can provide language specific descriptions as
|
|
|
|
\fBDescription.eng = Shades of blue\fR
|
|
.br
|
|
\fBDescription.ger = Blaut\(:one\fR
|
|
|
|
where the language code is added to the keyword
|
|
"Description", separated by a dot. You can enter as many language specific
|
|
descriptions as you like, but only those that have a corresponding locale
|
|
messages file will be actually used.
|
|
If a theme file doesn't contain a Description, the name of the theme (as
|
|
given in the theme's file name) will be used.
|
|
.SS AUDIO/VIDEO DATA
|
|
The files \fI00001.ts\fR...\fI65535.ts\fR are the actual recorded data
|
|
files. In order to keep the size of an individual file below a given limit,
|
|
a recording may be split into several files. The contents of these files is
|
|
\fBTransport Stream\fR (TS) and contains data packets that are each 188 byte
|
|
long and start with 0x47. Data is stored exactly as it is broadcast, with
|
|
a generated PAT/PMT inserted right before every independent frame.
|
|
.SS INDEX
|
|
The file \fIindex\fR (if present in a recording directory) contains
|
|
the (binary) index data into each of the the recording files
|
|
\fI00001.ts\fR...\fI65535.ts\fR. It is used during replay to determine
|
|
the current position within the recording, and to implement skipping
|
|
and fast forward/back functions.
|
|
See the definition of the \fBcIndexFile\fR class for details about the
|
|
actual contents of this file.
|
|
.SS INFO
|
|
The file \fIinfo\fR (if present in a recording directory) contains
|
|
a description of the recording, derived from the EPG data at recording time
|
|
(if such data was available). The \fBAux\fR field of the corresponding
|
|
timer (if given) is copied into this file, using the '@' tag.
|
|
This is a plain ASCII file and contains tagged lines like the \fBEPG DATA\fR
|
|
file (see the description of the \fIepg.data\fR file). Note that the lowercase
|
|
tags ('c' and 'e') will not appear in an \fIinfo\fR file.
|
|
Lines tagged with '#' are ignored and can be used by external tools to
|
|
store arbitrary information.
|
|
|
|
In addition to the tags used in the \fIepg.data\fR file, the following tag
|
|
characters are defined:
|
|
.TS
|
|
tab (|);
|
|
l l.
|
|
\fBF\fR|<frame rate>
|
|
\fBL\fR|<lifetime>
|
|
\fBP\fR|<priority>
|
|
\fB@\fR|<auxiliary data>
|
|
.TE
|
|
.SS RESUME
|
|
The file \fIresume\fR (if present in a recording directory) contains
|
|
the position within the recording where the last replay session left off.
|
|
The file consists of tagged lines that describe the various parameters
|
|
necessary to pick up replay where it left off.
|
|
|
|
The following tag characters are defined:
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fBI\fR@<offset into the file \fIindex\fR>
|
|
.TE
|
|
.SS MARKS
|
|
The file \fImarks\fR (if present in a recording directory) contains
|
|
the editing marks defined for this recording.
|
|
Each line contains the definition of one mark in the following format:
|
|
|
|
\fBhh:mm:ss.ff comment\fR
|
|
|
|
where \fBhh:mm:ss.ff\fR is a frame position within the recording, given as
|
|
"hours, minutes, seconds and (optional) frame number".
|
|
\fBcomment\fR can be any string and may be used to describe this mark.
|
|
If present, \fBcomment\fR must be separated from the frame position by at
|
|
least one blank.
|
|
|
|
The lines in this file need not necessarily appear in the correct temporal
|
|
sequence, they will be automatically sorted by time index.
|
|
|
|
If a frame position doesn't point to an I-frame of the corresponding recording,
|
|
it will be shifted towards the next I-frame (either up or down, whichever is
|
|
closer).
|
|
|
|
\fBCURRENT RESTRICTIONS:\fR
|
|
|
|
-\ the comment is currently not used by VDR
|
|
.SS EPG DATA
|
|
The file \fIepg.data\fR contains the EPG data in an easily parsable format.
|
|
The first character of each line defines what kind of data this line contains.
|
|
|
|
The following tag characters are defined:
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
\fBC\fR@<channel id> <channel name>
|
|
\fBE\fR@<event id> <start time> <duration> <table id> <version>
|
|
\fBT\fR@<title>
|
|
\fBS\fR@<short text>
|
|
\fBD\fR@<description>
|
|
\fBG\fR@<genre> <genre>...
|
|
\fBR\fR@<parental rating>
|
|
\fBX\fR@<stream> <type> <language> <descr>
|
|
\fBV\fR@<vps time>
|
|
\fBe\fR@
|
|
\fBc\fR@
|
|
.TE
|
|
|
|
Lowercase characters mark the end of a sequence that was started by the
|
|
corresponding uppercase character. The outer frame consists of a sequence
|
|
of one or more \fBC\fR...\fBc\fR (Channel) entries. Inside these any number of
|
|
\fBE\fR...\fBe\fR (Event) entries are allowed.
|
|
All other tags are optional (although every event
|
|
should at least have a \fBT\fR entry).
|
|
|
|
There may be several \fBX\fR tags, depending on the number of tracks (video, audio etc.)
|
|
the event provides.
|
|
|
|
.TS
|
|
tab (@);
|
|
l l.
|
|
<channel id> @is the "channel ID", made up from the parameters defined in 'channels.conf'
|
|
<channel name> @is the "name" as in 'channels.conf' (for information only, may be left out)
|
|
<event id> @is a 32 bit unsigned int, uniquely identifying this event
|
|
<start time> @is the time (as a time_t integer) in UTC when this event starts
|
|
<duration> @is the time (in seconds) that this event will take
|
|
<table id> @is a hex number that indicates the table this event is contained in (if this is left empty it will be set to 0x00; and value less than 0x4E it will be treated as if it were 0x4E)
|
|
<version> @is a hex number that indicates the event's version number inside its table (optional, ignored when reading EPG data)
|
|
<title> @is the title of the event
|
|
<short text> @is the short text of the event (typically the name of the episode etc.)
|
|
<description> @is the description of the event (any '|' characters will be interpreted as newlines)
|
|
<genre> @is a two digit hex code, as defined in ETSI EN 300 468, table 28 (up to 4 genre codes are supported)
|
|
<parental rating>@is the minimum age of the intended audience
|
|
<stream> @is the stream content (1 = MPEG2 video, 2 = MP2 audio, 3 = subtitles, 4 = AC3 audio, 5 = H.264 video, 6 = HEAAC audio)
|
|
<type> @is the stream type according to ETSI EN 300 468
|
|
<language> @is the three letter language code (optionally two codes, separated by '+')
|
|
<descr> @is the description of this stream component
|
|
<vps time> @is the Video Programming Service time of this event
|
|
.TE
|
|
|
|
This file will be read at program startup in order to restore the results of
|
|
previous EPG scans.
|
|
|
|
Note that the \fBevent id\fR that comes from the DVB data stream is actually
|
|
just 16 bit wide. The internal representation in VDR allows for 32 bit to
|
|
be used, so that external tools can generate EPG data that is guaranteed
|
|
not to collide with the ids of existing data.
|
|
.SS COMMANDLINE OPTIONS
|
|
If started without any options, vdr tries to read any files in the directory
|
|
/etc/vdr/conf.d with names that do not begin with a '.' and that end with '.conf'.
|
|
These files are read in alphabetical order. The format of these files is
|
|
|
|
# comment
|
|
.br
|
|
[name]
|
|
.br
|
|
-a
|
|
.br
|
|
-b 123
|
|
.br
|
|
--long
|
|
.br
|
|
--longarg=123
|
|
.br
|
|
|
|
Any lines that begin with '#' as the first non-whitespace character are considered
|
|
comments and are ignored.
|
|
A command line option file consists of one or more sections, indicated by '[name]',
|
|
where 'name' is either the fixed word 'vdr' (if this section contains options for
|
|
the main VDR program) or the name of the plugin this section applies to.
|
|
Each option must be written on a separate line, including the leading '-' (for
|
|
a short option) or '--' (for a long option). If the option has additional arguments,
|
|
they have to be written on the same line as the option itself, separated from the
|
|
option with a blank (short option) or equal sign (long option).
|
|
.SH SEE ALSO
|
|
.BR vdr (1)
|
|
.SH AUTHOR
|
|
Written by Klaus Schmidinger.
|
|
.SH REPORTING BUGS
|
|
Report bugs to <vdr\-bugs@tvdr.de>.
|
|
.SH COPYRIGHT
|
|
Copyright \(co 2013 Klaus Schmidinger.
|
|
|
|
This is free software; see the source for copying conditions. There is NO
|
|
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|