[mythtv] dtv_privatetypes

Mark Buechler mark.buechler at gmail.com
Wed May 24 18:17:36 UTC 2006


Daniel, how about a report of SDTs being inaccurate? This is the case with
me.

- Mark.

On 5/24/06, Daniel Kristjansson <danielk at cuymedia.net> wrote:
>
> On Wed, 2006-05-24 at 10:52 -0400, Yeasah Pell wrote:
> > Daniel Kristjansson wrote:
> > It seems like scanning and tuning is SDT-based now?
> Yep
>
> >  Are you aware that
> > some providers include many SDTs in a loop on the SDT PIDs, including
> > services from other transports (i.e. stuff that cannot even be received
> > on the current multiplex)?
> As current SDTs, or other SDTs? The scanner ignores other SDTs.
>
> > The worst case I know of is dishnet, where
> > you can expect to wait up to 30 seconds before seeing a SDT for services
> > on the current multiplex. I don't think SDT is going to be a good thing
> > to count on across the board, at least not when you need to do something
> > in a timely fashion. (Yes, I'm sure this is in opposition to some DVB
> > spec somewhere. The presence of such nonstandard behavior from providers
> > is why the privatetypes table existed in the first place!)
> I doubt the broadcaster doesn't send out the current SDT more often
> than the other SDT's.
>
> > Is PAT/PMT based tuning and scanning still available in some fashion?
> It is a fallback in scanning. At the moment PAT/PMT tuning is only enabled
> if the networkid or transportid is fields are zeroed. We may make SDT
> tuning optional if anyone reports an actual case of current SDT's being
> transmitted infrequently.
>
> > I also notice with some dismay that at least one part of the
> > privatetypes table has made a return as a hardcoded section of code (see
> > line 1200 of siscan.cpp) -- I really hope that anything that can't be
> > expressed in a general fashion can be put back into a db-driven system
> > like privatetypes represented in the past. A preference for PAT/PMT
> > tuning based on provider would be another thing that could go in the
> table.
> This is unlikely at the moment, the privatetypes table was not
> extensible to do the needs of eitfixups and the one line in siscan
> is not sufficient justification for all that privatetypes baggage.
>
> -- Daniel
>
> _______________________________________________
> 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/20060524/7db42697/attachment.htm 


More information about the mythtv-dev mailing list