yeasah at schwide.com
Wed May 24 16:06:08 UTC 2006
>> 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
>>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
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.
More information about the mythtv-dev