[mythtv] EIT active scanner

[Yeasah Pell]

Janne Grunau wrote:

>On Tuesday 13 June 2006 20:11, Yeasah Pell wrote:
>  
>
>>Some providers aggregate EIT for multiple transports onto a single
>>transport, so that only one out of a bunch of multiplexes will have
>>EIT data on it (but it will apply to the whole group of them)
>>    
>>
>
>Each transport should have at least now/next data. But your're right 
>it's rather pointless to tune to each multiplex if we can get the same 
>data from another multiplex. The only problem I see is to know if it's 
>indeed the same data.
>  
>
Ah right, I forgot about that. That sort of blows a hole in my idea of 
trivially identifying a reduced subset of transports to collect EIT from 
by just looking for the presence of EIT -- it's not just a problem of 
there not being anything there on some tps, just that it's fully 
redundant data that could be better acquired elsewhere. Darn it :-)

>  
>
>>Currently the active EIT scanner assumes that any multiplex with a
>>channel that uses EIT will have EIT available, which can result in a
>>lot of useless tuning activity (and potentially more rotor activity
>>than is needed)
>>    
>>
>
>The tuning activity is IMHO not really a problem. Rotor movement is. But 
>I'm pretty sure that there are no unnecassry rotor movement since we 
>scan the multiplexes grouped by source. 
>  
>
Right, the tuning activity is merely annoying and presumably makes EIT 
take longer to get populated (in terms of zero-to-fully populated 
guide), since you have to trawl through some number of transports before 
you hit the "motherlode" where all the good EIT data is. And the 
software presumably doesn't linger at the motherlode transport any 
longer than the others, so it could really slow guide acquisiton down as 
compared to just sticking with the relatively few transports that have 
the good EIT (though that's just a guess, I don't really know for sure)

The only reason it would increase rotor movement is if the EIT data is 
redundant across orbital positions -- i.e. you could get away with never 
moving the rotor at all for EIT (or never more than once for any given 
active scan anyway) in some cases.

>  
>
>>Does adding a field to the dtv_multiplex table that indicates the
>>presence of EIT seem like a good idea? This way we could watch for
>>EIT at scan time, and populate this field accordingly, and the active
>>scanner could use this information to determine that there's no point
>>in scanning a particular multiplex (since it isn't going to find any
>>EIT there)
>>    
>>
>
>One field isn't enough. The new eitscanner I'm currently working on 
>collects statistics of the data on each multiplex. I'm not sure if it's 
>necessary to save the statistics in the database.
>  
>
One boolean value is clearly enough to identify whether a multiplex has 
interesting EIT, but you're right in that there's no obvious way to 
populate the values automatically. I'm not sure what statistics you're 
collecting -- maybe there would be enough info in there to determine 
that certain transports are redundant subsets, and remove those from the 
list at runtime? Sounds like that could get tricky though (i.e. how 
carefully do you look at the data before concluding that one transport 
is a proper superset of another?), probably not worth it just to save on 
EIT acquisition time and possibly rotor movement.

>Janne
>
>ps: Your solution will lead to more rotor movements if you don't change 
>EITTransportTimeout accordingly
>  
>
Right, the default for EITTransportTimeout was presumably chosen with 
some average number of transports per orbital position in mind, and 
you'd need to change that if you had significantly less transports 
(whether it was from optimizing the EIT list or just because you have 
fewer transports on that satellite.) For rotor purposes, you really want 
something like EITSourceTimeout instead, and have the code work out how 
long to linger on each transport within each source based on the number 
of transports for that source.