[mythtv] Regarding EIT

[Janne Grunau]

On Mon, Jun 21, 2010 at 10:59:42PM -0600, Tyler T wrote:
> 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.

I'm working on major EIT scanning changes for 0.24. I'll comment on your
points on by one and say what I've changed or plan to change.

> 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:

The comment is true, it shouldn't hurt #2 (see below). Randomized start
is removed since there is only a single instance left. Planned to
prioritize by last scan time and available programming informations.

> 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.

I don't know how eit scanning interacts with with the HDHR but there
should be only one active EIT scan for each real card. The check in
libs/libmythtv/tv_rec.cpp line 1347 need to have the HDHR equivalent of
'(GetDVBChannel() || GetDVBChannel()->IsMaster())' added. At least for
DVB style cards there is no need to scan each channel on each multiplex.

> 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.

This shouldn't be necessary and isn't the case for DVB cards

> 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.

see above

> 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

All the logic which channel/multiplex to scan is moved to a single
backend thread. It makes it easier to decided when all multiplexes are
scanned. I intend to add an option to tell the scanner how often each
multiplex should be scanned each day (intended range 0-6 with 0 being
the current behavior). Could be easily extended to 24 but I don't see
the point.

> 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).

I think the how many scans per day option makes more sense and allows
idle shutdowwn of eitscanning backends.

> 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.

It's alone desireable for removing an then unneeded option. But hard to
implement correctly for all EIT systems.

> 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?

Even without in this case.

> 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?

I think you're main grumble will be resolved with fixing the bug in
tv_rec.cpp. I'll look into it this week if you don't beat me to it.
For the other changes you have to wait for 0.24 or use trunk after I'm
finished.

Janne