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

[Daniel Kristjansson]

On Sun, 2007-01-07 at 17:02 +0000, MythTV wrote:
> #2882: Poll CAM module at consistent intervals
> Comment (by david at hardeman.nu):
>  The reason that I didn't want to do it in CiHandlerLoop is that it calls
>  ciHandler->Process() which in turn also perform the other processing steps
>  (such as sending DateTime to the CAM module, etc), and delaying those
>  steps by up to 100ms might be a bad idea (I'm not sure whether it is).
So this would delay processing the PMT which could delay tuning,
makes sense.

>  Perhaps it would be an idea to try to get the patch applied to the vdr
>  sources?
This might be a good idea. We should also do a sync to their CAM code,
it's been a while since the last sync.

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

-- Daniel