frodovdr/vdr
1
0
Fork 0
mirror of https://github.com/vdr-projects/vdr.git synced 2025-03-01 10:50:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Version 1.7.30

Browse Source 
VDR developer version 1.7.30 is now available at

       ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.30.tar.bz2

A 'diff' against the previous version is available at

       ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.29-1.7.30.diff

MD5 checksums:

c6d75f2962bc3e22d9313c0ee4fa113a  vdr-1.7.30.tar.bz2
a63098efcc58bc697d6b890097d9c370  vdr-1.7.29-1.7.30.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.

The default skin "LCARS" displays the signal strengths and qualities of
all devices in its main menu. For devices that have an stb0899 frontend chip
(like the TT-budget S2-3200) retrieving this information from the driver is
rather slow, which results in a sluggish response to user input in the main
menu. To speed this up you may want to apply the patches from

   ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches

to the LinuxDVB driver source.

From the HISTORY file:
- Fixed sorting recordings in the top level video directory.
- Fixed handling control characters in SI data in case of UTF-8 encoded strings
   (thanks to Mehdi Karamnejad for reporting a problem with garbled UTF-8 EPG data
   and helping to debug it).
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- When checking whether a video directory is empty, file names that start with a
   dot ('.') are now ignored and will be implicitly removed if the directory contains
   no other files. This fixes the leftover ".sort" files that were introduced in
   version 1.7.29.
- Added IsUpdate() to the EPG handler interface (thanks to Jörg Wendel).
- Fixed detecting transfer mode on full featured DVB cards (thanks to Stefan Huelswitt
   for reporting a problem with updating CA descriptors in such cases).
- Fixed a race condition when zapping in transfer mode (reported by Reinhard Nissl).
   This involves a slight change in the semantics of the cReceiver::Activate() function,
   which is now called with 'false' after the receiver has been detached from the
   device.
- The new function cDevice::ReadFilter() can be used by devices to implement their
   own way of retrieving section filter data (thanks to Deti Fliegl).
- The new function cDevice::HasInternalCam() can be implemented by devices that
   provide encrypted channels in an already decrypted form, without requiring explicit
   handling of a CAM (thanks to Tobias Grimm).
- VDR can now be built according to the FHS ("File system Hierarchy Standard") by
   activating the line
   #USEFHS = 1
   in a copy of the file Make.config.template (thanks to Dennis Bendlin, as well as
   Christopher Reimer and Udo Richter for contributing to the patch).
- By default (without FHS support) the config directory is now set to the value
   given in the -v option if only -v and no -c is given.
- Fixed a long delay at the end when replaying a recording that has stopped recording
   less than an hour ago (typically time shift mode or a freshly edited recording).
- Fixed getting the file size and number of frames of ongoing recordings (only the
   timestamp of the recording's directory was checked, while it should have been that
   of the index file).
- Fixed sluggish response when manipulating editing marks while a cutting thread
   is running (reported by Torsten Lang).
- The new setup options "OSD/Color key [0123]" can be used to adjust the sequence
   of the color buttons displayed in the menus to that of the color keys on your
   remote control (based on a patch from Oliver Schinagl).
   Authors of plugins that implement skins may want to adapt their SetButtons()
   function in order to make use of this new feature. See, for instance, the function
   cSkinClassicDisplayMenu::SetButtons() in skinclassic.c for details.
This commit is contained in:
Klaus Schmidinger
2012-09-10 16:05:00 +02:00
committed by Dieter Hametner
parent 046b506748
commit d34026c18b
61 changed files with 914 additions and 216 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
PLUGINS.html
View File

@@ -82,7 +82,7 @@ structures and allows it to hook itself into specific areas to perform special a
<li><a href="#Wakeup">Wakeup</a>
<li><a href="#Setup parameters">Setup parameters</a>
<li><a href="#The Setup menu">The Setup menu</a>
<li><a href="#Configuration files">Configuration files</a>
<li><modified><a href="#Additional files">Additional files</modified></a>
<li><a href="#Internationalization">Internationalization</a>
<li><a href="#Custom services">Custom services</a>
<li><a href="#SVDRP commands">SVDRP commands</a>
@@ -885,39 +885,70 @@ You can first assign the temporary values to the global variables and then do th
your setup parameters and use that one to copy all parameters with one single statement
(like VDR does with its cSetup class).
<hr><h2><a name="Configuration files">Configuration files</a></h2>
<hr><h2><modified><a name="Additional files">Additional files</a></modified></h2>
<div class="blurb">I want my own stuff!</div><p>
There may be situations where a plugin requires configuration files of its own, maybe
for data that can't be stored in the simple <a href="#Setup parameters">setup parameters</a>
of VDR, or maybe because it needs to launch other programs that simply need a separate
configuration file. While the plugin is free to store such files anywhere it
sees fit, it might be a good idea to put them in a common place, preferably
where other configuration data already exists. VDR provides the function
<modified>
There may be situations where a plugin requires files of its own. While the plugin is
free to store such files anywhere it sees fit, it might be a good idea to put them in a common
place, preferably where such data already exists.
</modified>
<p>
<modified>
<i>configuration files</i>, maybe for data that can't be stored in the simple
<a href="#Setup parameters">setup parameters</a> of VDR, or maybe because it needs to
launch other programs that simply need a separate configuration file.
</modified>
<p>
<modified>
<i>cache files</i>, to store data so that future requests for that data can be served faster. The data
that is stored within a cache might be values that have been computed earlier or duplicates of
original values that are stored elsewhere.
</modified>
<p>
<modified>
<i>resource files</i>, for providing additional files, like pictures, movie clips or channel logos.
</modified>
<p>
<modified>
Threfore VDR provides the functions
<p><table><tr><td class="code"><pre>
<modified>
const char *ConfigDirectory(const char *PluginName = NULL);
const char *CacheDirectory(const char *PluginName = NULL);
const char *ResourceDirectory(const char *PluginName = NULL);
</modified>
</pre></td></tr></table><p>
which returns a string containing the directory that VDR uses for its own configuration
files (defined through the <tt><b>-c</b></tt> option in the call to VDR), extended by
<modified>
each of which returns a string containing the directory that VDR uses for its own
files (defined through the options in the call to VDR), extended by
</modified>
<tt>"/plugins"</tt>. So assuming the VDR configuration directory is <tt>/video</tt>
(the default if no <tt><b>-c</b></tt> or <tt><b>-v</b></tt> option is given),
a call to <tt>ConfigDirectory()</tt> will return <tt>/video/plugins</tt>. The first
call to <tt>ConfigDirectory()</tt> will automatically make sure that the <tt>plugins</tt>
subdirectory will exist. If, for some reason, this cannot be achieved, <tt>NULL</tt>
will be returned.
<modified>
The behavoir of <tt>CacheDirectory()</tt> and <tt>ResourceDirectory()</tt> is similar.
</modified>
<p>
The additional <tt>plugins</tt> directory is used to keep files from plugins apart
from those of VDR itself, making sure there will be no name clashes. If a plugin
needs only one extra configuration file, it is suggested that this file be named
<tt>name.conf</tt>, where <i>name</i> shall be the name of the plugin.
<modified>
needs only one extra file, it is suggested that this file be named <tt>name.*</tt>,
where <i>name</i> shall be the name of the plugin.
</modified>
<p>
If a plugin needs more than one such file, it is suggested that the plugin stores
these in a subdirectory of its own, named after the plugin. To easily get such a name
the <tt>ConfigDirectory()</tt> function can be given an additional string that will
be appended to the returned directory name, as in
<modified>
the functions can be given an additional string that will be appended to the returned
directory name, as in
</modified>
<p><table><tr><td class="code"><pre>
const char *MyConfigDir = ConfigDirectory(Name());
@@ -928,13 +959,16 @@ plugin's name. Again, VDR will make sure that the requested directory will exist
(or return <tt>NULL</tt> in case of an error).
<p>
<b>
The returned string is statically allocated and will be overwritten by subsequent
calls to ConfigDirectory()!
<modified>
The returned strings are statically allocated and will be overwritten by subsequent calls!
</modified>
</b>
<p>
The <tt>ConfigDirectory()</tt> function is a static member function of the <tt>cPlugin</tt>
class. This allows it to be called even from outside any member function of the derived
plugin class, by writing
<modified>
The <tt>ConfigDirectory()</tt>, <tt>CacheDirectory()</tt> and <tt>ResourceDirectory()</tt>
functions are static member functions of the <tt>cPlugin</tt> class. This allows them to be
called even from outside any member function of the derived plugin class, by writing
</modified>
<p><table><tr><td class="code"><pre>
const char *MyConfigDir = cPlugin::ConfigDirectory();
@@ -1888,6 +1922,7 @@ the functions
<p><table><tr><td class="code"><pre>
virtual int OpenFilter(u_short Pid, u_char Tid, u_char Mask);
<modified>virtual int ReadFilter(int Handle, void *Buffer, size_t Length);</modified>
virtual void CloseFilter(int Handle);
</pre></td></tr></table><p>