[mythtv] Ticket #1790: pes packet assembly in mythtv-eit
janne-mythtv at grunau.be
Thu May 18 00:49:55 UTC 2006
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
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
> 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.
More information about the mythtv-dev