vdr June 2010

vdr@linuxtv.org

58 participants
58 discussions

radio-0.2.5 compile error
by Mr Tux 07 Jun '10

07 Jun '10

Hello Simon Uwe offers a 1.7.x preversion (vdr-radio-0.9.0pre) on his webspace [1] - builds fine with 1.7.15 [1] http://www.egal-vdr.de/plugins/in_progress/20090905_vdr-radio-0.9.0pre.tgz >Simon Baxter <linuxtv at nzbaxters.com> wrote on Mon Jun 7 08:41:28 CEST 2010 >Under vdr-1.7.15 I'm getting this compile error: >Any ideas?

1 0

[ANNOUNCE] S2API wrapper + hard link cutter for VDR-1.7.13-15
by Udo Richter 06 Jun '10

06 Jun '10

Hi list, Once again, I'm a bit late with updating my patches. However, here are the new ones: DVB/S2API wrapper patch, to run VDR-1.7 under DVB API V3: New version of the patch for VDR-1.7.13 - VDR-1.7.15 http://www.udo-richter.de/vdr/patches.en.html#dvb-api-wrapper Hard Link Cutter patch, for fast editing of recordings: New version for VDR-1.7.14 - VDR-1.7.15 http://www.udo-richter.de/vdr/patches.en.html#hlcutter Cheers, Udo

2 3

How to pause live TV
by Scott 05 Jun '10

05 Jun '10

Hi, Pausing live tv with the pause button has never worked for me, must be something stupid but I can't see it. I use vdr 1.7.14, with vdr-xine 0.9.3 and xine-lib 1.1 When I press Pause I get 00.00.00 in the top right corner of the screen, the picture freezes and these messages appear in the log: Jun 5 18:28:12 giradot vdr: [31452] buffer usage: 60% (tid=31451) Jun 5 18:28:12 giradot vdr: [31452] buffer usage: 70% (tid=31451) Jun 5 18:28:12 giradot vdr: [31452] buffer usage: 60% (tid=31451) Jun 5 18:28:12 giradot vdr: [31452] buffer usage: 70% (tid=31451) Jun 5 18:28:13 giradot vdr: [31452] buffer usage: 80% (tid=31451) Jun 5 18:28:15 giradot vdr: [31452] buffer usage: 90% (tid=31451) Jun 5 18:28:15 giradot vdr: [31452] buffer usage: 100% (tid=31451) Pressing pause again resumes the playback but shortly after it skips to the current live position omitting a chunk of the program. These messages appear in the log: Jun 5 18:28:40 giradot vdr: [31452] ERROR: driver buffer overflow on device 1 Jun 5 18:28:44 giradot vdr: [31451] ERROR: skipped 11 bytes to sync on TS packe t on device 1 Jun 5 18:28:44 giradot vdr: [31451] TS continuity error (14) Jun 5 18:28:44 giradot vdr: [31451] TS continuity error (7) Jun 5 18:28:44 giradot vdr: [31451] cAudioRepacker(0xC0): skipped 552 bytes to sync on next audio frame Jun 5 18:28:47 giradot vdr: [31452] buffer usage: 60% (tid=31451) I thiink maybe xine is trying to do all the pausing itself instead of handing it off to VDR, but that's just a guess. The key binding for lirc and the pause button look ok, and the pause button works fine when playing back recordings. -- Scott

1 0

Re: [vdr] vdr 1.7.10 no record channel
by Senufo 05 Jun '10

05 Jun '10

Hi, Thanks Klaus Klaus I agree, but the video looks good because I can see this live stream and when I use the patch records are correct. I did a test with vdr 1.6.0 with the same channels.conf and there I can see the live stream and recordings works. Why ? Senufo On 05.05.2010 22:11, Senufo wrote: > > Hi, > > > > I found the problem. VDR does not detect the frame independent in this > > stream because in the function : > > > > cFrameDetector:: Analyze (const uchar * Data, int Length) > > > > in the file remux.c. > > > > ((Data [i +2]>> 3) & 0x07) is equal to 0 instead of 1 for stream that work. > > > > I applied this patch : > > > > --- remux.c 2010-05-04 14:55:50.000000000 +0200 > > +++ remux.c.orig 2010-05-04 21:57:38.000000000 +0200 > > @@ -960,6 +960,7 @@ > > return Processed; // flush everything before this new frame > > newFrame = true; > > independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame > > + if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;} > > if (synced) { > > if (framesPerPayloadUnit <= 1) > > scanning = false; > > > > and record is working again. > > I do not know what has changed in the stream. > > > > I tested this patch since yesterday and so far I have not had any problems. > > > > What do you think? > If this stream marks independent frames with '0' instead if '1', I would say it is broken. Klaus

2 1

Insufficient hardware PID filters on tuner
by Richard F 05 Jun '10

05 Jun '10

Hi list, Having another go at a long-standing problem on Freecom USB tuners - a bit more testing: Using VDR 1.6.0.2, and the problem seems to be that the tuners run out of hardware PID's. The problem can be reliably repeated tuning to BBC1 & BBC2 on freeview, when 1 channel is already recording on that multiplex What's appears unusual about these channels is that they need 4 PID's like so: May 10 17:36:54 ha-server vdr: [7018] changing pids of channel 1 from 600+600:601=eng,602=eng:0:0 to 600+600:601=eng,602=eng:605=eng:0 And tuning to another channel on that TS that uses 3 PID's (e.g BBC news) works OK: May 10 17:36:53 ha-server vdr: [7018] changing pids of channel 5 from 640+640:641=eng:0:0 to 640+640:641=eng:643=eng:0 The tuners report a capacity of 15 PID's from dmesg so: [ 42.437874] DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)) [ 42.449952] DVB: registering frontend 0 (WideView USB DVB-T)... [ 42.464022] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1d.7/usb4/4-3/input/input4 [ 42.475543] dvb-usb: schedule remote query interval to 300 msecs. [ 42.486250] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected. [ 42.755308] usb 4-5: new high speed USB device using ehci_hcd and address 5 [ 42.895930] usb 4-5: new device found, idVendor=14aa, idProduct=0221 [ 42.907350] usb 4-5: new device strings: Mfr=1, Product=2, SerialNumber=0 [ 42.918743] usb 4-5: Product: Digital TV Receiver [ 42.930060] usb 4-5: Manufacturer: Digital TV Receiver [ 42.941813] usb 4-5: configuration #1 chosen from 1 choice [ 42.953252] dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state. [ 42.967224] dvb-usb: will use the device's hardware PID filter (table count: 15). Some basic investigation... Looking at the PID's being used during recording of a single channel, using lsof -n | grep adapter1.demux0 I see : vdr 7008 vdr 7u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 15u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 21u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 22u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 24u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 26u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 27u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 34u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 35u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 36u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 37u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 39u CHR 212,68 6038 /dev/dvb/adapter1/demux0 So 12 filters in use, which is several more than needed by the channel being recorded (I assume these are other channels being monitored for epg etc, or is this other stuff in the TS being filtered...?). When nothing is being recorded the following is typically output: vdr 7008 vdr 7u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 15u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 21u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 22u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 24u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 26u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 27u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 28u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 39u CHR 212,68 6038 /dev/dvb/adapter1/demux0 Sometimes this count is lower (e.g. 8, in which case 2 channels can be recorded). When it fails, VDR still tries to allocate the PID's for the channel that requires 4: May 16 19:47:51 ha-server vdr: [7022] ERROR: /dev/dvb/adapter1/demux0: Too many open files May 16 19:47:51 ha-server vdr: [7022] ERROR (dvbdevice.c,658): Too many open files Sometimes, after multiple retries, the 2 channels fit the total of 15 (presumably some other PID's discarded) and it records 2 channels OK. Then after stopping 2 simultaneous recordings (BBC1 + BBC2), and the residual PID count is now just 5. vdr 7008 vdr 7u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 15u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 21u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 22u CHR 212,68 6038 /dev/dvb/adapter1/demux0 vdr 7008 vdr 26u CHR 212,68 6038 /dev/dvb/adapter1/demux0 The question is can the total PID count be reduced when VDR is idle, or is there an assumption that a channel uses fewer than 4 PID's in calculating how many to leave spare for recordings (if that's how it works)? Or is it that these USB sticks are just old now, and I need one that has more hardware filters - if so does anyone have recommendations? Thanks!

2 1

epgsearch 0.9.24 conflict check problem??
by Simon Baxter 04 Jun '10

04 Jun '10

Have just upgraded vdr-1.6.0 to epgsearch plugin version 0.9.25.beta16 because of an increasing problem with 0.9.24 and timer conflicts. 0.9.24 was reporting timer conflicts where none existed - 0.9.25.beta16 seems to have resolved this problem! Happy days :)

2 1

[ANNOUNCE] tsplay-0.2 patch for VDR-1.6.0-2
by Udo Richter 03 Jun '10

03 Jun '10

Hi list, The tsplay patch for VDR-1.6.0 is available in version 0.2. The new version is updated with some backport changes from VDR-1.7, and adds the missing patch presence detection. More important, there are patches for streamdev-cvs and xineliboutput-cvs that add compatibility to tsplay to these plugins. Playback of ts recordings over xineliboutput on VDR-1.6 should finally be possible. Get it at: http://www.udo-richter.de/vdr/patches.en.html#tsplay Cheers, Udo

1 0

Re: [vdr] VDR and ACPI wakeup for recording
by Eric Valette 01 Jun '10

01 Jun '10

On 05/31/2010 03:58 PM, Gerald Dachs wrote: >> On 05/31/2010 03:14 PM, Hanno Zulla wrote: >> >>> Hi, >>> >>> >>> >>>> 1) Has this already been integrated to vdr? >>>> >>>> >>> A working ACPI wakeup script was written by Tobi in 2003 and has been >>> maintained by him as a debian package since then: >>> >>> <http://www.e-tobi.net/vdr-experimental/pool-sid/source/addons/vdr-addon-acp…> >>> >>> It works nicely on my system, after turning off HPET on boot. >>> >>> >> Thank for this part of the script. Job is half done at least. >> > I use it already for years and didn't notice that something is missing. > Could you please enlighten me what is missing? > Read: http://www.vdr-portal.de/board/archive/75121/thread.html where the guy complains about not having the wakeup file or please post your own script (or the link) especially the part that writes the WAKEUP_FILE="/var/cache/vdr/acpiwakeup.time". Readding the scripts I do not know what part of the software is going to write /var/cache/vdr/acpiwakeup.time and also I shall manually set wake up time in the config file. What I would like is using the stored planned recording information to automatically deduce the next wakeup time. -- eric

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr June 2010