[mythtv] dtv_privatetypes

[Yeasah Pell]

>> 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.
>  
>
I'm honestly not sure how to tell the difference. Is that determined by 
the current_next_indicator? All the SDTs are set to "1" (valid now) -- I 
could send you a dvbsnoop log if you'd like, though it'd be pretty 
large. It's somewhat irrelevant though, because...

>
>I doubt the broadcaster doesn't send out the current SDT more often
>than the other SDT's.
>  
>
...the 30 second interval was measured *between SDTs that are for the 
current multiplex* -- that means you WILL be waiting up to 30 seconds 
for any SDT that is interesting to you, probably on average around 15 
seconds.

>  
>
>>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 don't see any issues with it being a fallback during scanning -- if 
there's an extra timeout that needs to happen, big deal -- so scanning 
takes longer, and presumably having the SDT is beneficial and worth the 
wait. It's not like anybody goes and runs a scan every day or anything.

Tuning is the bigger deal -- obviously telling people to zero their 
networkid and transportid is not going to fly when 0.20 is released to 
the masses -- the natural solution IMO would have been to add a few 
lines to the privatetypes table that notified the tuning code to use 
PAT/PMT tuning when the network ID matched this and that, and to add 
lines to that table as they were reported by users.

>  
>
>>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.
>
>  
>
So because the table wasn't flexible enough for one particular use case 
it should be discarded and replaced with hardcoded values in the program 
code? I'm not sure what eliminating the table saved, even if there's 
only one special-case line that is used *right now*.

Surely even the non-extensible table as it existed previously would be 
flexible enough to handle the PAT/PMT vs. SDT issue (it's just a boolean 
flag per network ID), and it seems rather short-sighted to eliminate a 
data-driven way to override behavior just because most of the current 
usages have been replaced with smarter code.

I have a hard time believing the code will ever be smart enough to 
eliminate the usefulness of being able to change behavior on a 
per-network-ID basis -- even if it can be made to *function* without it 
(i.e. fallback tuning, and whatever else), it can be made to function 
*better* when you have a mechanism to tell the system more about the 
non-standard behavior of a provider instead of having it have to figure 
it out by runtime observation.

I'm not saying privatetypes should be retained exactly in its old form, 
I don't really care what form the functionality takes. I'm just saying 
that a data-driven facility to conditionally change behavior is valuable 
and something to fill that need should be included.