[mythtv] DVB EIT in mythtv-eit

Fri May 5 11:39:02 UTC 2006

Janne Grunau wrote:

>On Thursday 04 May 2006 17:12, Rudy Zijlstra wrote:
>  
>
>>Janne Grunau wrote:
>>    
>>
>>>On Thursday 04 May 2006 10:40, Rudy Zijlstra wrote:
>>>You will see one NIT with table id 0x40 (actual network) and maybe
>>>several other with table id 0x41 (other networks). Each NIT
>>>regardless of the table id value will hold one one or more
>>>transport descriptors.
>>>      
>>>
>>Fine, this explains why network scanning on my cable network always
>>fails. The network ID i have to give the STB is 1111. The NIT which
>>is selected that way has a table id of 0x41 (other network).
>>I guarantee though, that it is the valid NIT for my location.
>>
>>This is common cable behaviour. This was recorded on Essent in the
>>Netherlands.
>>    
>>
>
>I can only say that Kabel Deutschland does the right thing(tm). They 
>have only one NIT actual network and no NITs fo other networks.
>  
>
Yup

>>>>Important 1: only the TS referred to by the NIT with the correct
>>>>network ID will be present on the cable!
>>>>        
>>>>
>>>Cabel, satellite, terestial transmitter, something like that but it
>>>doesn't depend on the network id, but the table id matters.
>>>      
>>>
>>See above. I happen to disagree. More importantly, so does my cable
>>provider. (and most cable providers in EU).
>>    
>>
>
>At least Kabel Deutschland (biggest cable provider in germany) seems not 
>to suck regarding DVB standard conformance.
>
>  
>
Urrrr..... lets ignore some special cases?

>>For SAT there is yet another reason to scan by network ID. When you
>>have payTV, you have a subscription with Premiere, C+, ...
>>At that point you are interested in services from them, and not from
>>another. So in all cases you are interested in receiving a minority
>>(the services you have a subscription on). This can be done by
>>scanning on network ID.
>>    
>>
>
>Please be precise: you want to filter the scanning on the 
>original_network_id? I'm pretty sure that the NIT on premiere 
>transponders (Astra 19.2E) do also carry information for transponder 
>with a different original_network_id. But I'don't understand why you 
>wouldn't like to have the FTA programs even if you have a pay TV 
>subscription. A better feature would be to add only encrypted channels 
>you have valid subscription for.
>
>  
>
Thats what i meant. FTA with only those encrypted i have valid 
subscription for. At the moment you get ALL encrypted channels (which is 
only cluttering EPG info).

>>>>Important 2: The different network layouts may (and will) overlap.
>>>>Leading to different TS having the same frequency. Of course, only
>>>>1 will actually be present (see 1).
>>>>        
>>>>
>>>We handle only the NIT with table id 0x40. So this is not a problem
>>>at all.
>>>      
>>>
>>And so any scanning i do on my DVB-C tuner fails.
>>    
>>
>
>Since your cable provider can't read or does not want to fulfill the 
>DVB-specs. I have some ideas how to make scanning on specs-violating 
>networks working but that will have to wait until the scanner works for 
>standard conforming networks. This is hard enough.
>
>  
>
Please keep in mind that for many cable operators fullfilling that 
particular aspect will:
- incur significant extra cost, with no added benefit to them
- Many have installed legacy STB which already handle this particular 
behaviour since way before 2004. Changing your operating environment to 
keep up with changing standards is not something they are very willing 
to do, as the risk involved to operating procedures (read: black TV 
screens) is significant. They will implement new features without 
disturbing old ones. KDG is has started digitizing late.

>>>>Important 3: this means you cannot tune based on SDT info. There is
>>>>no 1-1 mapping between SDT and NIT.
>>>>        
>>>>
>>>Of course there is. In the NIT of the actual network each transport
>>>is specified by original_network_id and transport_stream_id. For
>>>every combination of this two should exist only one SDT.
>>>      
>>>
>>In theory, yes. In practice: No.
>>    
>>
>
>Also in practice! At least for some networks. 
>  
>
Operative word: some

>  
>
>>>>Important 4: The same services will be referenced in different TS.
>>>>(from different NIT). I actuality only 1 NIT is valid, and only 1
>>>>TS will actually carry the service.
>>>>        
>>>>
>>>Not a problem, we get the service information from the SDT of the
>>>actual tuned transport. And there is only one SDT for each actual
>>>transport.
>>>
>>>I haven't read your previous mail (was it send directly to Daniel?).
>>>It might be that your cabel provider is incompetent and does not
>>>rewrite the NITs in the transport streams it provides. But please
>>>wait with
>>>      
>>>
>>I am willing to forward to the provider management. Do you want his
>>answer on this one?
>>    
>>
>
>I doubt that they will answer at all. But I'm interested to hear why the 
>violate the DVB-specs or choosed to follow their own "standard".
>  
>
See above. "standard" is correct though. There is none.

>  
>
>>By the way, your cable provider is most likely Telenet. As far as i
>>know they do not use NIT-actual at all.
>>    
>>
>
>Don't be confused by my email address. I'm from BErlin.
>  
>
Hmm,  be is country designation for BElgium. Why don't you follow the 
standard? Berlin is part of Germany, so should it not be de?

>  
>
>>>complaints until the channel scanner is working for standard
>>>conforming DVB networks.
>>>      
>>>
>>Some information for you: none of them (DVB-C) comply in that way....
>>They tend to have 1 central HE, and distribute over their complete
>>territory without having Multiplexors in between. So NIT is
>>determined in the HE for all possible networks they have. And they
>>tend to have several network layouts.
>>    
>>
>
>At least Kabel Deutschland in Berlin complies.
>
>  
>
>>For germany in case of private network you actually have to ignore
>>the NIT in many cases. Many of those networks take a signal from SAT,
>>trans-modulate to QAM and transmit without touching the NIT.
>>    
>>
>
>Some other small and broken setups. The tuned scan should work. It may 
>not give correct channel names.
>  
>
Perhaps small, but still significant. Because there actually are quit a 
few of them. This occurs precisely because they are small, and do not 
have the finances available to re-muliplex.

>Janne
>  
>
Rudy