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

Mark Buechler mark.buechler at gmail.com
Wed May 17 16:45:10 UTC 2006

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.

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.

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, 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.

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.

- Mark.

On 5/17/06, Janne Grunau <janne-mythtv at grunau.be> wrote:
> On Wednesday 17 May 2006 16:18, Daniel Kristjansson wrote:
> > On Wed, 2006-05-17 at 09:52 -0400, Mark Buechler wrote:
> > > Daniel, zero'ing out the networkid and transportid enables me to
> > > tune just fine.
> >
> > Ok, then that sounds fine as a work-around for this broken SDT
> > problem for now. I'll sync the EIT tree to svn head then and so we
> > can start applying those outstanding patches to the EIT tree.
> Im not 100% sure that the assembly is without bugs but it is working
> Stuart Auchterlonie, me and another guy from irc. But if there is a
> problem we can sort it out later.
> Another minor problem is that consecutive recordings fail. Stuart has
> discovered it and I'm able to reproduce it. The problem seems to be
> that we finished not only the first recording but also the second. When
> TVRec is ready to start the second tuning fails sice the tuningrequest
> is empty. I haven't tested trunk or anything other than DVB recordings
> yet. relevant log excerpt: http://pastebin.ca/56336
> I'm not too happy with the previous global eitscanner patch. I've
> started to redoing it and I will probably move all EIT processing to
> that single thread. This will make it easier to limit the load of EIT
> processing.
> > One solution would be to just add a "tuning_method" column to the
> > channel table, but I'd prefer a workaround that doesn't require this,
> > or at least detects this problem in the channel scan and set this
> > "tuning_method" column automatically.
> Waiting not longer than 6 seconds for a SDT is maybe a viable
> workaround. If it's a standard conform DVB stream we should have seen 3
> SDTs. If not we can shout out a "missing SDT" warning and tune with
> only PMT and PAT. The only loss of PMT-PAT-tuning is that can't be sure
> if it is the desired service.
> 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/e55d6403/attachment.htm 

More information about the mythtv-dev mailing list