[mythtv] Ticket #1790: pes packet assembly in mythtv-eit

[Janne Grunau]

On Wednesday 17 May 2006 18:45, Mark Buechler wrote:
> Waiting 6 seconds is a long time when you're tuning. Not only that
> but if you consider people with rotors (like myself), this could
> result in falling back to the PAT when a perfectly good SDT is
> available if it takes > 6 seconds to move the dish.

The timer should only start after seeing a matching PAT. And it will 
only take six seconds if there is no good SDT. And if there's no SDT 
after six second we can blame the provider for breaking the standard 
and point a way to change the signalmonitoring method.

> I've been giving some thought to some points Janne brought up when I
> asked him why we don't look at the NIT/network_id instead of the
> SDT/original_network_id. Using the latter just doesn't seem right to
> me. I suppose my concern comes from the fact that I use a rotor.

That doesn't matter.

> The original_network_id isn't necesarily unique accross multiple
> providers. It is very possible to have two completely different
> providers rebroadcast the same SID/TID/original_network_id,

There are different providers rebroadcasting the same channels with 
identical SID/TID/original_network_id. I doubt that it's possible to 
receive this rebroadcasted streams with the same card but it doesn't 
really matter.
If we got a service with matching SID/TID/original_network_id, we got 
the correct service (except the providers are messing very bad with the 
DVB specs).

> whereas 
> comparing to the (current) network_id in the NIT you're very nearly
> guarenteed to be tuned to the correct transponder. The only scenario 
> this would fail in is if a given provider had two or more
> transponders with the same TID broadcasting the same SID - something
> which is extremely unlikely to happen.

We don't know the TSID except we parse the complete NIT and compare the 
all transport descriptors with the tuning data but then we know the 
original_network_id too. Parsing the entire NIT just for tuning is 
silly. Plus some providers use the same temporary network_id.
So we can't be sure that we are indeed tuned to the desired service even 
if all values match.

> Now, I realize that EIT requires that we compare against the
> original_network_id since EIT tables don't contain the (current)
> network_id. Given that, I believe there should be another column
> added to the db which contains the original_network_id to be used
> with EIT scanning.

I'm against this. I think it's pretty much pointless to add a extra 
signalmonitoring method for some broken DVB provider if the method for 
mpeg streams works.

This NIT-based signalmonitoring shouldn't be used for DVB multiplexes. 
It has only disadvantages compared with the SDT based approach. It is 
not reliable, it is slower (2 against 10 seconds worst case) and it 
will force every DVB user to rescan her/his channels.

Janne