vdr September 2010

vdr@linuxtv.org

48 participants
72 discussions

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

ATSC missing program discription on some channels
by Timothy D. Lenz 03 Sep '10

03 Sep '10

Using the ATSC epg plugin I get all program names, but some channels just say no information. But if you check the same channels with a converter box, they do have program information. I was told there is a flag that is checked. If the flag is not set by the broadcaster, the program info is not looked for. Need a patch to disable the check and always look for the information.

1 0

streamdev doesn't suspend live TV
by Michal 03 Sep '10

03 Sep '10

Hi, I think there is a bug in the way streamdev switches the channel before it starts streaming. I have only 1 tuner and suspend behaviour in streamdev-server is set to "always suspended". Unfortunately streaming doesn't stop live TV when the channel is on a different transponder. Streamdev switches the channel in cConnectionHTTP::ProcessRequest(), but before streaming is started the channel is switched back on a different thread in the main while loop in vdr.c (the statement with comment "Make sure we have a visible programme in case device usage has changed"). Michal

3 2

no tv image, recording is ok
by Torsten Mohr 03 Sep '10

03 Sep '10

Hi, on my VDR PC i've set up openSuse 11.3 and i configured and compiled vdr-1.7.15 from source (no RPM). I also installed kernel 2.6.35 (compiled myself) with DVB support for my Technisat CableStar HD2. First test: Starting kaffeine, the card is detected and channels can be scanned. But if i select a channel i hear sound for half a second, then kaffeine crashes. No TV image could be seen before. I configured and installed w_scan, i got a Channels.conf with it that looks ok. I then configured and compiled softdevice-1.6.0 (with changes to make it compile). I can start vdr -P"softdevice -vo xv:" and see the VDR menu in a window. I can see the channels and also start recording. I can view the recorded stream with MPlayer, great quality. But i can see no TV image in VDR. Can anybody tell me what i need to change or what additional tests i need to do to see TV output in VDR? Best regards, Torsten.

1 0

Re: [vdr] New ATSC Video Type 0x80?
by Rolf Ahrenberg 03 Sep '10

03 Sep '10

On Thu, 2 Sep 2010, Rob Davis wrote: > I will attempt to diagnose tomorrow, probably by adding another Case 0x80 > under Case 2 in pat and remux but wanted to point this out for future > reference as I know most of the development is done outside of the ATSC > world.. If you'll take a look at the table 7.4 in ANSI/SCTE 57, you'll see that the stream type 0x80 is DigiCipher2 video and 0x81 is used for AC-3: http://www.scte.org/documents/pdf/standards/ANSISCTE572003DVS507.pdf IMO, the current "channel->IsAtsc()" check in pat.c should be replaced with a stream identification via the registration descriptor. > Then it's back to working out why my pvr-hd ac-3 (h264 and ac3 @ 720p) don't > work in vdr-xine and xbmc/vnsi.. (although do work in vdr-xineliboutput and > xbmc/streamdev..) I guess XBMC/VNSI is using their own PMT parser, so you'll have to add these same hacks into them. BR, -- rofa

1 0

New ATSC Video Type 0x80?
by Rob Davis 03 Sep '10

03 Sep '10

I am trying to get my head around ATSC / AC3 and have discovered some ATSC Clear Qam channels disappear when update channels is on. Some playing around with pat.c and the isyslog command, I have discovered they appear to have a different type than normal.. Normally Mpeg2 is type 2, but these are 0x80? I notice they do the same thing with AC-3 (0x81 instead of 6) so probably something similar is going on. Sep 2 23:11:29 oac vdr: [5815] pat.c stream type = 80, pid = 2240 Sep 2 23:11:29 oac vdr: [5815] pat.c stream type = 81, pid = 2241 Sep 2 23:11:29 oac vdr: [5815] pat.c wants to update channel Sep 2 23:11:29 oac vdr: [5815] changing pids of channel 355 from 0+0=0:0;2241=@106:0:0 to 2240+2240=128:0;2241=@106:0:0 If hard coded with vpid and pid of 2240=2 and update channels of, then the picture shows. I will attempt to diagnose tomorrow, probably by adding another Case 0x80 under Case 2 in pat and remux but wanted to point this out for future reference as I know most of the development is done outside of the ATSC world.. Then it's back to working out why my pvr-hd ac-3 (h264 and ac3 @ 720p) don't work in vdr-xine and xbmc/vnsi.. (although do work in vdr-xineliboutput and xbmc/streamdev..) -- Rob Davis

1 0

Understanding AC-3
by Rob Davis 02 Sep '10

02 Sep '10

Hi Guy's, 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). I have a Hauppauge PVR-HD and two ATSC cards. The ATSC cards work as they should and with the new atsc/dn patch on 1.7.15 now have the correct dpids. However, if I turn on add new transponders or update pids, then my Hauppauge PVR channels lose their dpid values.. Sep 1 19:10:33 oac vdr: [8186] changing pids of channel 920 from 4113+4097=27:0;4352=eng@106:0:0 to 4113+4097=27:0:0:0 If I keep automatic channel updates off, then xineliboutput and streamdev work for these channels, but vdr-vnsi (xbmc) and vdr-xine don't (no audio).. I'm assuming vdr parses the ac3 headers in some way and sends information onto the playback frontend. How would I go about seeing what those headers might be and looking into patching pat.c accordingly? I noticed all the comments about e-ac3 and wonder if a similar patch should be made for this device. As an aside, vdr recordings from these channels play back fine in vdr-xine. So, more specifically, I suppose I would like to know how to find out the STREAMTYPE: I'm pretty sure it falls under this: case 6: // STREAMTYPE_13818_PES_PRIVATE But I'd be interested in seeing the flow through this section of pat.c and what is happening.. Mainly to see if something needs to be forced on? I can create a five second VDR recording if someone wants to see what the TS stream looks like.. But I'd be interested in diagnosing it myself.. Thanks. -- Rob Davis

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr September 2010