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

[Mark Buechler]

Adding an additional 6 seconds to tuning for these users of a "broken"
standard isn't the kindest thing to do when you consider many of them have
gotten used to ~2 seconds for tuning.

I don't know that I agree with the 10 vs 2 second comparison. Granted, that
is what the standard dictates, however, given we know not all providers
follow the standard I think we should match on which ever we find first -
for the fastest tuning possible. Or at last give the user the choice in an
advanced dialog. I suspect you'll find that many providers send out their
NIT more frequently than every 10 seconds. I also suspect you'll find that
the NIT is smaller than the SDT in most cases. But again, I am only familiar
with the providers available to me.

Whatever is decided, I just hope that users don't end up with a less
functional version than they had prior to mythtv-eit being rolled in. I'm
sure I'm not the only DVB user of a provider who chooses to not follow the
standard completely.

- Mark.

On 5/17/06, Janne Grunau <janne-mythtv at grunau.be> wrote:
>
> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060517/3fdb5a2a/attachment.htm