Zsolt Barat | 30 Oct 12:35 2015

Frequency as float in channels.conf

Dear List,
I need to change the frequency value in channels.conf to a float value
xxxxx.75. But since only INT values are allowed here I wonder how to
achieve this.
Any advice?

Thanks and regards


vdr mailing list
vdr <at> linuxtv.org

Andy Carter | 30 Oct 07:27 2015

DXR3 cards

I have two DXR3 cards if anyone has a need for one. 

Avitus brand, 32bit PCI

I've had them a long time, not used in years but kept just in case. 
No guarantee they are working now - but no reason why not :)

Post to UK/EU only


vdr mailing list
vdr <at> linuxtv.org

Teemu Suikki | 26 Oct 00:19 2015

Softhddevice, 10 dupes per second


I was recently using Yavdr with no real problems, but now I decided to
build my own VDR system on top of Linux Mint. Main reason was that
Yavdr stable still doesn't have vdr 2.2.0..

I've got everything working nicely, but I have weird "duped frames"
problem with softhhddevice. Video and audio are fine and nicely in
sync, and usually you can't see anything wrong. But fast moving
objects sometimes have "tearing" and jerky movement.

Also if I open Softhddevice stats from the VDR main menu, I see that
"duped" field increases steadily maybe 9-10 per second! "dropped" and
"missed" stays at zero usually.

There is nothing special on the log. Sometimes I get logs like this:

Oct 26 01:09:42 puucee vdr: video: slow down video, duping frame
Oct 26 01:09:42 puucee vdr: video: 22:17:22.060  +55  311   0/\ms  23+7 v-buf
Oct 26 01:10:29 puucee vdr: video: slow down video, duping frame
Oct 26 01:10:29 puucee vdr: video: 22:18:09.380  +53  285   0/\ms  26+7 v-buf

But as you can see, these are almost a minute apart, and the actual
"duped" count increased by several hundreds already during that time.
So this logged "duping" is normal a/v sync, what I see is something

This is VDR 2.2.0, and quite recent softhddevice from yavdr ppa:

(Continue reading)

Nicolas Huillard | 25 Oct 11:44 2015

Raspberry Pi, satip, MLD

Hi all,

I still have a problem with my new setup:
* Raspberry Pi B (256MB system + 256MB video)
* MLD 5.0.0 testing distribution (http://www.minidvblinux.de/) on a 4GB
class 6 SD card, using VDR
* vdr-plugin-rpihddevice (from MLD 1:2015.08.24-37+
* Octopus Net (firmware 1.0.55) : Linux VLC shows TV channels without
* vdr-plugin-satip (from MLD 2015.09.19-20+
* recordings on an NFS share (works for playing, didn't test recording)
* the Raspberry is powered from one of the 5V output from the Octopus,
which provides enough power for the CI interface, which seems

Playing live TV works great, until some point a few dozen minutes later,
where some errors start to appear in /var/log/messages:

Oct 25 10:51:59 vdrpi user.err vdr: [17414] ERROR: 1 ring buffer overflow (940 bytes dropped)
Oct 25 10:52:01 vdrpi user.info vdr: [17414] SATIP: Detected 1 RTP packet errors [device 0]
Oct 25 10:52:05 vdrpi user.err vdr: [17414] ERROR: 496 ring buffer overflows (652736 bytes dropped)
Oct 25 10:52:11 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows (768544 bytes dropped)
Oct 25 10:52:17 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows (768544 bytes dropped)
Oct 25 10:52:23 vdrpi user.err vdr: [17414] ERROR: 580 ring buffer overflows (763280 bytes dropped)
Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: [libav] Header missing
Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: failed to decode audio frame!
Oct 25 10:52:31 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in Transfer Mode
Oct 25 10:52:31 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
Oct 25 10:52:38 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in Transfer Mode
Oct 25 10:52:38 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz

(Continue reading)

Matthias Lötzke | 18 Oct 23:36 2015

Unable to compile media_build_experimental drivers on Debian stable

Hello All,

I has been using http://linuxtv.org/hg/~endriss/media_build_experimental
for quite some time now. Until recently I never encountered a problem.
Now I can't build any more:

> make -C /home/matthias/tmp/media_build_experimental/v4l 
> make[1]: Entering directory '/home/matthias/tmp/media_build_experimental/v4l'
> scripts/make_makefile.pl
> ./scripts/make_myconfig.pl
> perl scripts/make_config_compat.pl /lib/modules/3.16.0-4-amd64/source ./.myconfig ./config-compat.h
> creating symbolic links...
> xargs: ln: Too many levels of symbolic links
> Makefile:264: recipe for target 'links' failed
> make[1]: *** [links] Error 126
> make[1]: Leaving directory '/home/matthias/tmp/media_build_experimental/v4l'
> Makefile:28: recipe for target 'all' failed
> make: *** [all] Error 2
> build failed at ./build line 491.

I am using Debian stable with Kernel 3.16.0-4-amd64. Some hundreds maybe
thousands of symlinks are being created where the build fails.

Any solution or hint would be highly appreciated.

Best regards


(Continue reading)

Thomas Reufer | 18 Oct 10:16 2015

[ANNOUNCE] rpihddevice plugin 1.0.0

Hi all

rpihddevice-1.0.0 is now available!

VDR HD output device for Raspberry Pi. The plugin makes use of the Raspberry
Pi's VideoCore GPU and provides a lightweight implementation for a VDR output

- MPEG-2 and H264 high-profile video codec up to 1080p30
- MPEG-1 Layer II, (E)AC-3, AAC and DTS audio codec at 32kHz, 44.1kHz or 48kHz 
  with 2.0 (Stereo) or 5.1 channels
- HDMI multi channel LPCM audio output
- HDMI digital audio pass-through
- Analog stereo audio output
- Box (letter-box/pillar-box), Crop and Stretch video display modes
- True color OSD with GPU support
- Video scaling and grabbing support



Recent changes:
2015-10-18: Version 1.0.0
- new:
(Continue reading)

Morfsta | 18 Sep 11:21 2015

Re: DVB-T2 device in France

On Thu, Sep 17, 2015 at 8:58 PM, Karim <karim.afifi <at> laposte.net> wrote:

I use TBS6280 (dual tuner, pci-e) from Turbosight in dvb-t mode (no dvb-t2
signal here): good card, not expensive and great technical support. Newer
model is TBS 6281 :


I hope it helps.

I have the TBS6281 and have found that the drivers from TBS are a pain to get co-existing at the same time with other kernel DVB drivers (e.g. my Prof USB DVB-S2 device) and need re-installing after every kernel update.  Also, I think that the open source drivers do not support DVB-T2.

However, on the positive side once the driver is installed, the card is stable.

vdr mailing list
vdr <at> linuxtv.org
Nicolas Huillard | 17 Sep 14:01 2015

DVB-T2 device in France

Hello all,

My previous mail to this ML is apparently dated 2011 ;-) Everything was
OK there since then... Except that my Hauppauge Nova-T-500 died
recently, and my ancient PCI cards do not work in the 2013 server.

I'm looking for advice for a new DVB-T2 device, which should :
* have a good tuner, because some channels (transponders, ie.
frequencies) are difficult to catch here ; the TV set (Panasonic) works
perfectly well, and I've added an RF amplifier on the roof, so I guess
the Nova-T-500 tuner was not good enough
* have a PCI or preferably PCI-e bus, and dual tuner (I don't really
like USB sticks, which tend to lead to a mess of cable)
* be robustly supported with stock kernels in Debian (jessie and
future), which does not seem to be a problem anymore...

If there are some dual-tuner, DVB-T2 + S2 card out there which are well
supported by VDR, that's OK too. I may prefer to add another DVB-S2 card
later on though (there is no sat-dish on the roof yet).




vdr mailing list
vdr <at> linuxtv.org

Klaus Schmidinger | 14 Sep 16:24 2015

[ANNOUNCE] VDR developer version 2.3.1

VDR developer version 2.3.1 is now available at


A 'diff' against the previous version is available at


MD5 checksums:

391c2ed60e2f7d24563fe3ed5854bc4f  vdr-2.3.1.tar.bz2
983fd4bad7d19cd98301d54173107129  vdr-2.2.0-2.3.1.diff


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 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

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.

The changes since version 2.2.0:

- 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
- 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
- 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
   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
   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(),
   + 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
   + 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
       cStateKey StateKey;
       if (cTimers *Timers = cTimers::GetTimersWrite(StateKey)) {
          // access the timers
     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).

Have fun!


vdr mailing list
vdr <at> linuxtv.org

Timo Eskola | 8 Sep 13:38 2015

[ANNOUNCE] Duplicates plugin 0.1.0


Shows duplicate recordings.

Changes in 0.1.0:
- Added hiding of duplicate recordings.
- Updated German translations, thanks to Joerg Bornkessel.

Homepage for the plugin:

vdr mailing list
vdr <at> linuxtv.org
Richard F | 1 Sep 21:58 2015

DVB Subtitle stream help please

I've been testing my H264 conversion script, and come across a problem with the VDR 1.6 subtitles

VDR 1.6 (.vdr) recordings
The subtitle stream is reported by VLC as type "subtitle",  "codec: DVD subtitles (spu)"
ffmpeg reports  "Stream #0:2[0x20]: Subtitle: dvd_subtitle"
For reasons unknown, subtitles do not show on VLC (although you can select the subs track), Kodi, mplayer and ffplay
VDR 2.20 + VOMP 0.4.1 shows subtitles CORRECTLY, so they exist in the stream.

VDR 2.20 (.ts) recordings
ffmpeg reports  "Stream #0:3[0x131](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)"

Subtitles show on VLC, ffplay and VDR 2.20 + Kodi (using VNSI)
Subtitles do not show on VDR 2.20 + VOMP 0.4.1

ffmpeg reports no subtitle data when transcoding / copying the VDR 1.6 streams, even when forcing the codec to "dvb_subtitle"
Obviously if possible I would like to retain the subtitle data when transcoding around 8 years of recordings.

Could someone please confirm :

a) Is there an issue with VOMP on VDR 2.20 re: subtitles and old VDR 1.6 recordings ?
b) Is there a Linux or windows video player that shows subtitles in VDR 1.6 (.vdr) recordings ?
c) Is there a magic switch in FFMPEG or other tool to recognise / transcode / export the "DVD subtitles" ? Or another program ?

If all else fails, I assume it's possible to extract the data using functions in old VDR 1.6 code, but that might be a bit involved...

Thanks !

vdr mailing list
vdr <at> linuxtv.org