vdr

vdr@linuxtv.org

2 participants
6731 discussions

[ANNOUNCE] VDR version 2.0.0 released
by Klaus Schmidinger 01 Apr '13

01 Apr '13

VDR version 2.0.0 is now available at ftp://ftp.tvdr.de/vdr/vdr-2.0.0.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.42-2.0.0.diff MD5 checksums: fd7f481b996e03fae3c00e80b6b0d301 vdr-2.0.0.tar.bz2 db1fc075c567bf75c566de6ce3cb4a0b vdr-1.7.42-2.0.0.diff A summary of all the major changes since the last stable version 1.6.0 can be found at http://www.tvdr.de/changelog.htm When updating from an earlier version of VDR please make sure you read the INSTALL and MANUAL files that come with the VDR source _before_ doing so! Please make sure you have backup copies of all your configuration files, and verify carefully that your timers will be set to the correct channels after switching to this new version. Thanks to the many people who have contributed in the making, testing and debugging of this new version of VDR. Please also visit the newly refurbished VDR homepage at http://www.tvdr.de and VDR's new facebook page at https://www.facebook.com/VideoDiskRecorder Have fun! Klaus

8 8

[ANNOUNCE] S2API Wrapper Light 0.10 for VDR-2.0
by Udo Richter 31 Mar '13

31 Mar '13

Hi, I've uploaded the newest version of S2API Wrapper 'light', the wrapper patch to VDR that ensures DVB API compatibility to all DVB 5.0 API kernel headers. The new version fixes the DVB-S2 EPG bug that was introduced with 1.7.40, whenever the runtime kernel had DVB API 5.7 or less. To do so, the wrapper queries the API version of the running kernel, and switches to legacy code depending on that. At the same time, some of the VDR compile-time code switches depending on DVB API version of the kernel/driver headers were converted to runtime kernel switches. All in all, with the patch VDR should compile on all DVB header versions from 5.0 upwards, and all DVB features should be available as long as the runtime kernel supports them. Get it here: http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper http://www.udo-richter.de/vdr/patches.html#dvb-api-wrapper Cheers, Udo

1 0

Channel update on HD transponders broken?
by Udo Richter 31 Mar '13

31 Mar '13

Hi list, I've noticed that I don't get channel updates any more on most of the German HD transponders, since my update from 1.7.37 to 1.7.41 on 2013-03-16. I'm running VDR in "add new transponders" full update mode. I didn't check 1.7.42 yet, sorry. I'm running a very minimal old patch that tracks the time of the last channel update, so I'm pretty sure that the channel update stopped exactly at 2013-03-16 for all channels on the following 19.2E transponders: 10773 (ANIXE HD/BetaDigital), 10802 (ASTRA 3D Demo/BetaDigital), 11082 (RTL HD Austria), 11170 (OrangeSAT), 11302 (ORF1 HD), 11332 (Syfy HD/SKY), 11361 (ZDF HD), 11464 (ProSieben HD), 11493 (Das Erste HD). All other transponders get updated normally. To check whether channel update works, try to edit the channel name of Das Erste HD. Channel update should restore the original name almost instantly. First, can someone reproduce this with their VDR? I don't want to stop the presses unnecessarily. Cheers, Udo

4 4

Markad
by Marx 31 Mar '13

31 Mar '13

I would like to enable ad marking in markad plugin. Does it work only for HD channels? Does it need to have defined channel logos somewhere? Can you recommend some guide/blog entry/description about markad? Marx

3 2

Absolutely last chance for translations for VDR version 2.0.0!
by Klaus Schmidinger 29 Mar '13

29 Mar '13

VDR version 2.0.0 is going to be released this Sunday, March 31. This is the absolutely last chance to have all OSD texts translated into your local language. After tomorrow, March 30, 15:00 (3pm) CET I won't adopt any more patches to *.po files. The languages not yet translated completely are da_DK.po: 134 el_GR.po: 197 hr_HR.po: 134 nn_NO.po: 262 pt_PT.po: 28 sl_SI.po: 1 tr_TR.po: 134 Klaus

1 0

[ANNOUNCE] VDR Power Button Daemon 0.0.1
by Manuel Reimer 29 Mar '13

29 Mar '13

Hello List, I have written a small daemon, which can replace acpid on VDR systems and was written with dedicated VDR systems in mind. Core Features: - Faster than acpid with all the required external scripts. - Emergency reboot feature. You don't loose the power button as safe emergency exit button. Just press it four times within three seconds and a clean reboot is triggered. - Very easy to set up. If you want, you can just copy the "vdrpbd" file to your VDR system and execute it. VDR should react to the power button immediately! - Systemd integration. If systemd is detected, then vdrpbd tries to register itself as "power button inhibitor". The module "Net::DBus" is required for this to work. Note that it requires an up-to-date kernel, as the only supported way, to access the power button, is the input layer. There is no "netlink" support and I also won't add it. Download from here: http://projects.vdr-developer.org/attachments/download/1331/vdrpbd-0.0.1.ta… To post bug reports and feature requests, you may use the ticket system here: http://projects.vdr-developer.org/projects/vdrpbd/issues/new Or just answer to this mail and tell me about your opinion and/or give feature requests. Yours Manuel Reimer

4 7

[PATCH] MaxThemeName and MaxSkinName limit
by Lucian Muresan 27 Mar '13

27 Mar '13

Hi, thank you Klaus for holding up your release plan for 2.0! However, I hope this minor patch won't be too much trouble for you, as it only increases the limit of 16 to theme and skin names, letting them be NAME_MAX as almost any files, since these names can also be involved in file names. Was there a good reason to limit them at 16 only, perhaps the fear that the name won't fit on the OSD? I don't really think someone would really make use of as many as 255 characters for this. On the other hand, users just encountered crashes with plugins which (unfortunately, yet) have themes of their own, when just adding a new theme with a name longer than 16 and at the same time the original plugin author relied on MaxThemeName when allocating the string length. So, what do you think, easy to adopt? Regards, Lucian

11 29

Problem with vdr and a Hauppage WinTV-Duet
by Marc 27 Mar '13

27 Mar '13

Hi, I try to use a new receiver (Hauppage WinTV-Duet, a dual dvb-t usb receiver) but it doesn't work. When I start vdr, I can see them in vdr : vdr: [16411] new device number 3 vdr: [16436] section handler thread started (pid=16411, tid=16436, prio=low) vdr: [16411] frontend 2/0 provides DVB-T with QPSK,QAM16,QAM64 ("DiBcom 7000PC") vdr: [16411] probing /dev/dvb/adapter3/frontend0 vdr: [16411] creating cDvbDevice vdr: [16411] new device number 4 vdr: [16439] section handler thread started (pid=16411, tid=16439, prio=low) vdr: [16438] tuner on frontend 2/0 thread started (pid=16411, tid=16438, prio=high) vdr: [16411] frontend 3/0 provides DVB-T with QPSK,QAM16,QAM64 ("DiBcom 7000PC") but when I try to use one of them, vdr complains with the following message : vdr: [16438] frontend 2/0 timed out while tuning to channel 7, tp 562 (same message for the second adapter) I can see the green led switching on (witch means vdr access the adapter) but only for a few seconds before the above message. vdr tries again without success. There is no more log with loglevel 3. I tried manually and everything works : tzap -a 2 -r -c ~/tzap.chan "France 2" using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0' reading channels from file '/root/tzap.chan' tuning to 586000000 Hz video pid 0x0078, audio pid 0x0082 status 1f | signal ac22 | snr 00d5 | ber 001fffff | unc 0000007d | FE_HAS_LOCK status 1f | signal abe6 | snr 00dd | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal abdb | snr 00d8 | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal abaa | snr 00e6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK ... then, I can see the channel with mplayer in /dev/dvb/adapter2/dvr0. Are there some parameters in vdr to get my adapter working ? Thanks, Marc.

1 0

[PATCH] VDR 1.7.42: fix pending timers
by Klaus Schmidinger 26 Mar '13

26 Mar '13

There has been a bug report regarding overlapping "pending" timers. The original posting can be found here: http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1134445-proble… The diagram "version 2" shows 3 timers with different priorities, where timers 1 and 3 can record simultaneously, while timer 2 can only record by itself. This is due to limitations imposed by "device bonding", but similar situations may also occur in other environments. The problem here is that at time 'C', timer 3 starts and forces timer 2 to stop due to its higher priority. Now timer 1 would also be able to record, but it doesn't do so until timer 2 expires. This is caused by timers 1 and 2 being in the "pending" state, but timer 2 always being chosen in cTimers::GetMatch(time_t t) due to its higher priority. The attached patch fixes this. Please apply and test it. I'm considering to include this in the final version 2.0.0 which shall be released on sunday, so I need to know whether it causes any negative side effects. Klaus

1 0

Re: [vdr] Like VDR on facebook!
by master.of.brainless.things＠gmx.net 26 Mar '13

26 Mar '13

facebook hat doofe ohren... -- "The significant problems we face cannot be solved at the same level of thinking we were at when we created them." -Albert Einstein

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr