[vdr] [BUG] VDR incorrectly sets caid on FTA channel

[Klaus Schmidinger]

On 20.12.2009 19:50, Francesco Saverio Schiavarelli wrote:
> Hello,
> 
> I found a problem with VDR 1.6.0 with the following channel:
> 
> cielo:12034:vC34:S13.0E:27500:166:414=ita,415=und:476:0:11110:64511:6600:0
> 
> If I set "Update channels" to "names and pid" that line gets updated:
> 
> cielo:12034:vC34:S13.0E:27500:166:414=ita,415=und:476:919,93B:11110:64511:6600:0
> 
> 
> and the channels becomes unavailable even if audio and video pids are
> _unscrambled_.
> 
> After a short investigation with dvbsnoop I think I've found the culprit
> (excerpt from PMT table dump follows):
> 
> Stream_type: 5 (0x05)  [= ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private
> sections]
> reserved_1: 7 (0x07)
> Elementary_PID: 2085 (0x0825)
> reserved_2: 15 (0x0f)
> ES_info_length: 27 (0x001b)
> 
>     MPEG-DescriptorTag: 15 (0x0f)  [= private_data_indicator_descriptor]
>     descriptor_length: 4 (0x04)
>     Descriptor-data:
>         0000:  4f 54 56 00                  OTV.
> 
>     DVB-DescriptorTag: 144 (0x90)  [= User defined/ATSC reserved]
>     descriptor_length: 1 (0x01)
>     Descriptor-data:
>         0000:  9d                              .
> 
>     DVB-DescriptorTag: 254 (0xfe)  [= User defined]
>     descriptor_length: 4 (0x04)
>     Descriptor-data:
>         0000:  54 47 54 00                  TGT.
> 
>     MPEG-DescriptorTag: 9 (0x09)  [= CA_descriptor]
>     descriptor_length: 4 (0x04)
>     CA_system_ID: 2329 (0x0919)  [= News Datacom (Videoguard)]
>     reserved: 7 (0x07)
>     CA_PID: 1603 (0x0643)
> 
>     MPEG-DescriptorTag: 9 (0x09)  [= CA_descriptor]
>     descriptor_length: 4 (0x04)
>     CA_system_ID: 2363 (0x093b)  [= News Datacom (Videoguard)]
>     reserved: 7 (0x07)
>     CA_PID: 1703 (0x06a7)
> 
> 
> There is a private data stream declared in the channel PMT that contains
> CA_descriptor and so the whole channel is treated like scrambled.
> 
> The actual vdr approach, although correct in principle, seems a bit too
> conservative to me. There are cases where a channel is completely
> unavailable even if just one component is unavailable because of
> scrambling.

Please try the attached patch.

Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vdr-1.7.10-patcadescr.diff
Type: text/x-patch
Size: 2362 bytes
Desc: not available
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20091224/d1bfe1fe/attachment.bin>