[mythtv] dtv_privatetypes

[Daniel Kristjansson]

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