vdr

vdr@linuxtv.org

2 participants
6731 discussions

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
by Simon Baxter 05 Sep '10

05 Sep '10

> On 05.09.2010 21:59, Simon Baxter wrote: >>> Looks like there are TS packets in your stream that are marked as >>> "scrambled", but not unscrambled by the CAM. >>> >>> Do you have any CAM in your system at all? >> >> Yes. System has 2x TT-1501-C cards and Alphacrypt CAMS >> >>> Are the channels where this happens scrambled? >> Yes >> >>> Do these channels have separate VPID and PPID? >> channels.conf looks like: >> ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=eng@4:579:606:1005:182:10:0 >> TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=eng@4:580:606:1006:182:10:0 >> TV3;T:578000:C0M64:C:6900:1303=2:1403=@4:712:606,5601:1003:182:10:0 >> >> >>> Does the problem go away if, instead of the above change, you >>> comment out the line >>> >>> (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) && >>> >>> in cReceiver::AddPids()? >> Yes - that fixes the problem....

1 1

Re: [vdr] vdr-1.7.15 problem with live TV [1.7.11 or older OK] [PROGRESS :) ]
by Simon Baxter 05 Sep '10

05 Sep '10

> Looks like there are TS packets in your stream that are marked as > "scrambled", but not unscrambled by the CAM. > > Do you have any CAM in your system at all? Yes. System has 2x TT-1501-C cards and Alphacrypt CAMS > Are the channels where this happens scrambled? Yes > Do these channels have separate VPID and PPID? channels.conf looks like: ONE;T:578000:C0M64:C:6900:1305+1205=2:1405=eng@4:579:606:1005:182:10:0 TV2;T:578000:C0M64:C:6900:1306+1206=2:1406=eng@4:580:606:1006:182:10:0 TV3;T:578000:C0M64:C:6900:1303=2:1403=@4:712:606,5601:1003:182:10:0 > Does the problem go away if, instead of the above change, you > comment out the line > > (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) && > > in cReceiver::AddPids()? I can't find that in cReceiver::AddPids() Do you mean in "bool cReceiver::SetPids(const cChannel *Channel)": bool cReceiver::SetPids(const cChannel *Channel) { numPids = 0; if (Channel) { channelID = Channel->GetChannelID(); return AddPid(Channel->Vpid()) && // (Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) && ?

2 1

check cam status
by Simon Baxter 05 Sep '10

05 Sep '10

Hello I'm needing to reset my CAM periodically, and in order to do this I need to check it's status from outside VDR. I've been doing the following, which is not ideal: if [ $((`tail -n $LINES /var/log/messages | grep 'vdr:' | grep 'ERROR' | grep 'CI' | wc -l`)) = 0 ] to test for: "May 22 00:49:45 freddy vdr: [9061] ERROR: can't write to CI adapter on device 1: Input/output error " messages and then: "while [ $((`tail -n $LINES /var/log/messages | grep 'dvb_ca adapter 1: DVB CAM detected and initialised successfully' | wc -l`)) = 0 ]" to test it's recovered Does anyone have any better suggestions???

2 6

vdr-1.7.15 problem with TV
by Simon Baxter 05 Sep '10

05 Sep '10

Hi I've just installed vdr-1.7.15 on my development box which has a single TT-2300 DVB card and CAM installed. I'm using vdr-xine as my front end. When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable. logs look like this: Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available! The same setup works fine under vdr-1.6.0. Any ideas?

10 30

Multiple tuners and reception error recovery without emergency exit
by Petri Helin 05 Sep '10

05 Sep '10

Hi, I was wondering whether what I experienced yesterday is really the way VDR functions at the moment. I have two tuner cards, one in pci slot and another connected via usb. While VDR was running I disconnected the antenna cable from the pci card in order to connect it to a hd cable ready set-top box. This resulted in a 0 sized recording due to VDR not switching the tuner to the one still connected to the antenna. You can see this in the following log entries: Aug 28 17:31:56 vdrkone2 vdr: [1282] frontend 0/0 provides DVB-C ("VLSI VES1820 DVB-C") Aug 28 17:31:56 vdrkone2 vdr: [1282] frontend 1/0 provides DVB-C ("Philips TDA10023 DVB-C") Aug 28 17:31:56 vdrkone2 vdr: [1344] tuner on frontend 0/0 thread started (pid=1282, tid=1344) Aug 28 18:36:30 vdrkone2 vdr: [1344] frontend 0/0 lost lock on channel 1, tp 274 Aug 28 18:36:32 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 1, tp 274 Aug 28 18:37:26 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 1, tp 274 Aug 28 18:37:53 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 1, tp 274 Aug 28 18:38:11 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 7, tp 274 Aug 28 18:39:14 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 7, tp 274 ... Aug 28 21:55:00 vdrkone2 vdr: [1282] switching device 1 to channel 7 Aug 28 21:55:00 vdrkone2 vdr: [1282] timer 1 (7 2155-2351 'Tapaus Wilson (K15)') start Aug 28 21:55:00 vdrkone2 vdr: [1282] Title: 'Tapaus Wilson (K15)' Subtitle: '(null)' Aug 28 21:55:00 vdrkone2 vdr: [1282] record /data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec Aug 28 21:55:00 vdrkone2 vdr: [1282] creating directory /data/video/Tapaus_Wilson_(K15) Aug 28 21:55:01 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 7, tp 274 Aug 28 21:55:13 vdrkone2 vdr: [1282] creating directory /data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec Aug 28 21:55:13 vdrkone2 vdr: [1282] recording to '/data/video/Tapaus_Wilson_(K15)/2010-08-28.21.55.7-0.rec/00001.ts' Aug 28 21:55:13 vdrkone2 vdr: [5921] recording thread started (pid=1282, tid=5921) Aug 28 21:55:14 vdrkone2 vdr: [1348] channel 2 (TV2) event La 28.08.2010 21:55-22:05 'Urheiluruutu' status 4 Aug 28 21:55:14 vdrkone2 vdr: [1282] max. latency time 14 seconds Aug 28 21:55:44 vdrkone2 vdr: [5921] ERROR: video data stream broken Aug 28 21:55:44 vdrkone2 vdr: [5921] emergency exit request ignored according to setup Aug 28 21:56:04 vdrkone2 vdr: [1344] frontend 0/0 timed out while tuning to channel 7, tp 274 As you can see, I have turned the emergency exit off, but I'd have thought that VDR would have been able to try the other tuner without emergency exit being activated. However, this does not seem to be the case. Is there any reason for that? -Petri

2 1

DIVX recordings? :)
by Teemu Suikki 05 Sep '10

05 Sep '10

I know this is probably too much to ask at this moment when there just has been a transition to TS.. Anyway, here it goes. :) I often compress my older recordings to Divx, to save space. However I never remember to watch them because they don't show up in VDR recordings anymore. :) I know I can watch them with the Mplayer plugin, but it's not convenient, especially if you are recording some series and half of the episodes are divx and half VDR.. So basicly I would like to be able to compress vdr recording to divx, but still view it like normal VDR recording. It would be quite enough to simply launch mplayer-plugin for the file if divx format is detected? Editing etc is not necessary at all. This is probably something I can do myself, but I just thought I ask in case someone else has already done something similar. :) -- Teemu Suikki http://www.z-power.fi/

2 1

pvr-testing2 xbmc discussion
by Rob Davis 04 Sep '10

04 Sep '10

Does anyone know where this is happening now? I know the xbmc forum was down for a while, but this discussion never seemed to happen again afterwards. -- Rob Davis

5 9

Sort recordings by content descriptor
by J.W. 03 Sep '10

03 Sep '10

Hi, since vdr-1.7.11 the content descriptor tag in the epg meta data is supported. It would be a nice feature to be able to sort the recordings by this content descriptor in the recordings menu. Because not all TV stations are sending sensible content descriptors, these should be editable. This would help to keep a better overview of the own recordings collection. Best regards, Joachim

1 0

Re: [vdr] Understanding AC-3
by Rolf Ahrenberg 03 Sep '10

03 Sep '10

On Fri, 3 Sep 2010, Rob Davis wrote: > Do we need to check it's ATSC if type is 0x81? Does anything else use it and > is it a problem if it does? The values 0x80-0xFF are so called User Private in the standard, so in theory you cannot assume them to be ATSC. But you could detect the ATSC streams from their registration descriptor (hopefully) and after that adapt dynamically to ATSC video and AC-3 pids. BR, -- rofa

1 0

Re: [vdr] Understanding AC-3
by Rolf Ahrenberg 03 Sep '10

03 Sep '10

On Thu, 2 Sep 2010, Rob Davis wrote: > How do you go about understanding AC-3 within a VDR context? > (apart from reading up on it online - which now has my head spinning). The current ATSC AC-3 support requires the 'A' source type for channels and therefore VDR never use ATSC hacks for any pvrinput channel. A quick and dirty hack would be adding an additional check for the pvrinput source type into cChannel::IsAtsc(). BR, -- rofa

2 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