vdr

vdr@linuxtv.org

2 participants
6731 discussions

[ANNOUNCE] VDR developer version 2.3.1
by Klaus Schmidinger 10 Oct '15

10 Oct '15

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. 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 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). Have fun! Klaus

2 1

Which DVB-S / DVB-S2 cards are recommended?
by Christian Rodriguez 02 Oct '15

02 Oct '15

Hello! I'm new to satellite systems, so I would like to buy a cheap card, considering decrypting streams. The question is about which hardware is recommended to run with VDR, that can decode encrypted traffic Thanks in advance! -- Lic. Christian A. Rodriguez @car_unlp

8 10

DVB-T2 device in France
by Nicolas Huillard 28 Sep '15

28 Sep '15

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). TIA ! -- NH

6 9

Re: [vdr] DVB-T2 device in France
by Morfsta 18 Sep '15

18 Sep '15

On Thu, Sep 17, 2015 at 8:58 PM, Karim <karim.afifi(a)laposte.net> wrote: > Hi, > > 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 : > > http://www.linuxtv.org/wiki/index.php/TBS6281 > > I hope it helps. > Regards. 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.

3 2

[ANNOUNCE] Duplicates plugin 0.1.0
by Timo Eskola 08 Sep '15

08 Sep '15

Description: Shows duplicate recordings. Changes in 0.1.0: - Added hiding of duplicate recordings. - Updated German translations, thanks to Joerg Bornkessel. Homepage for the plugin: http://projects.vdr-developer.org/projects/plg-duplicates

1 0

DVB Subtitle stream help please
by Richard F 01 Sep '15

01 Sep '15

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

1 0

[ANNOUNCE] Duplicates plugin 0.0.6
by Timo Eskola 27 Aug '15

27 Aug '15

Description: Shows duplicate recordings. Changes in 0.0.6: - Added patch from Joerg Bornkessel: - New Makefile handling up from vdr-1.7.34 - Completed german translation. - Minor fixes in .po files Homepage for the plugin: http://tolleri.net/vdr/

1 0

Reception of 27.5W
by Luboš Doležel 16 Aug '15

16 Aug '15

Hi, I'm trying to receive BBC-SATBACK from 27.5W. I surely won't go into any decryption details here. I can play *all* of the channels in the transponder in VLC via the "TS" stream from vdr-streamdev. In case of "PES" streams, however, I can only play the SD channels (MPEG-2 audio & video), but none HD channels (H.264 video and AAC audio). No data come in. A similar problem happens with vdr-xvdr: SD channels work, HD channels don't. This is what appears in the log: Aug 16 14:22:50 [vdr] [11075] cAudioRepacker(0xC0): skipped 230 bytes while syncing on next audio frame Aug 16 14:23:06 [vdr] [11075] ERROR: no useful data seen within 10501304 byte of video stream Could you guys please point me at what could cause this? Decryption is apparently working given that TS streams work... Thanks! -- Luboš Doležel

1 0

xmltv2vdr.pl
by Dominic Evans 14 Aug '15

14 Aug '15

I don't know if anyone else still uses the xmltv2vdr.pl perl script for piping XMLTV data into VDR's epg, but I've been keeping a version of it updated with some additional function here: https://github.com/oldmanuk/xmltv2vdr These are the changes since the last version (1.0.9) was released on the mailing list - Add support for XMLTV episode-num. Currently gets added as EPG entry 'sub-title', if no existing subtitle has been found, in the form sXXeXX (e.g., Bones~s01e01). - Change default SVDRP port number to 6419. - Better support for ATSC/PVRINPUT EPG sources. - Allow multiple channels to have the same XMLTV channel id, useful for multi input (e.g., DVB-T, DVB-S) systems where you want to feed VDR the same info. Previously only a 1:1 mapping was permitted. I've also received a pull request from someone who rewrote the whole script to be a lot more readable and to use full XML parsing (rather than just line-by-line scraping), but I still need to investigate what the performance penalty is before accepting that in.

6 10

vdr on arch linux, and on debian wiki
by cedric.dewijs＠telfort.nl 07 Aug '15

07 Aug '15

Hi All, I have started 2 articles about VDR, one on the arch linux wiki, and one on the debian wiki. on the arch linux wiki, there are a lot of people who edit the article, but on debian i am the ony one. I don't understand why. Could it be that vdr is a sensitive subject for debian? What are your thoughts about this? https://wiki.debian.org/VDR?action=info https://wiki.archlinux.org/index.php?title=Digitenne&action=history Kind regards, Cedric

3 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr