[mythtv] Regarding EIT

[Tyler T]

Per a thread over on -users, I'm playing around with the EIT code
(0.23) to stop it from constantly scanning for EPG data. However, the
more I dig into it, I more I feel some aspects need to be discussed.

1. EIT randomizes the channel scanning sequence. I can't imagine why
this would be necessary... anyone care to explain? There is a code
comment "This is so that multiple cards with the same source don't all
scan the same channels in the same order when the backend is first
started up" but I think this hurts more than it helps when it comes to
#2:

2. I have my single-tuner HDHR set up with 4 "virtual tuners" (for
multi-rec). This causes 4 EIT threads to all queue up passive scans,
which is silly on a single tuner. It would make sense if multiple
threads could scan different sub-channels on the same multiplex
simultaneously, but the previously mentioned randomization code
completely defeats this.

3. Even without channel sequence randomization, each EIT passive scan
thread will exit at different times (due to the rate limiting on the
rescheduler), and thus slowly drift away from each other until you can
no longer scan sub-channels simultaneously anyway.

4. It seems like either a) there should be only 1 EIT thread per
actual tuner, NOT per virtual tuner, or, b) there needs to be 1 master
EIT thread per tuner that can spawn sub-threads to scan sub-channels
and subsequently kill them when the tuner moves off that channel.

BTW, all this stems from my original desire to limit active EIT
scanning to one pass per hour. I kind of got it working, except the 4
threads will all finish at different times and slowly drift apart
until the backend is constantly scanning again anyway. This brings me
to alternative

4. c), which would be to un-randomize and set a global "trigger"
variable 1 hour hence, and then have each EIT sub-thread adopt that
time as their next-scan-start-time. That way after scanning once and
going to sleep, they all fire off simultaneously again a set time
later (and of course we then increment that global trigger again 1
hour hence).

5. Another (separate) enhancement to consider is, rather than scanning
a channel for X minutes, scan until you start seeing EIT data for the
second time (so you know you've got the whole broadcast loop), then
stop until the next trigger time. That of course would take a whole
lot more work for not a lot of efficiency benefit, so perhaps that
isn't feasible.

Anyway, I'm content to hack 4c just for my own use, but it seems like
there are some enhancements here that should maybe be merged back in
to the project. I don't mean to denigrate the original EIT code
author, as the code is stable and does the job nicely -- it's just
that I have an itch to scratch here and that's what OSS is all about.
Sadly, while I have done a lot of programming in procedural languages,
this C++ stuff is greek to me. If I submit a feature enhancement
request for any of the above, is there a snowball's chance it will get
worked on by someone? Or can I just keep pestering you guys here with
newb C++ questions as I try to muddle through 4c on my own? And if I
do manage get 4c working, is there any chance it will be accepted back
into mainline MythTV?

This is my first foray into participating in OSS at this level, so
please don't jump on me if I'm committing a faux-pas here.

I appreciate your thoughts...

Thanks,
___
 /yler