[mythtv] [mythtv-commits] Ticket #2882: Poll CAM module at consistent intervals

[David Härdeman]

On Sun, Jan 07, 2007 at 02:08:48PM -0500, Daniel Kristjansson wrote:
>On Sun, 2007-01-07 at 17:02 +0000, MythTV wrote:
>>  Talking about the CiHandlerLoop: currently there is a usleep(250) in
>>  there, with some debugging code I found that the loop is executed approx.
>>  950 times/sec on my machine, which seems a bit excessive.
>>  I've tried bumping the usleep to 2500, 10000 and 90000 (so 2.5, 10 and 90
>>  ms precision), and there seems to be no ill effects. Do you know why the
>>  current value is so low? Perhaps the usleep should be changed?
>I've just bumped it up to 10 ms. In all honesty the CAM module
>is not very actively maintained. It's the only DVB code in
>MythTV which is still just a wrapper around VDR code. This
>is just because no one has stepped up to clean this up and
>none of the committers uses a CAM. We really shouldn't have
>a tight usleep loop like this, but rather we should trigger
>processing with a QWaitCondition for things like the PMT update
>plus a longer usleep (or rather a QWaitCondition timeout)
>to take care of things like polling the CAM module.

Yes, that seems like a reasonable approach, it requires a much larger 
rewrite though since the timeout differs at all stages depending on 
where in the state machine we are (e.g. if a status poll has been sent 
to the CAM, the timeout is 350 ms while the timeout until the next poll 
after a succesful poll is 100 ms).

The optimal solution would probably be one that combined a poll (for 
incoming data from the module) with a state-specific timeout and 
support for other interrupting events (such as a new PMT or TDT).

I think that some inspiration can be found in the libdvben50221 library.

-- 
David Härdeman