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

Andrew Lyon andrew.lyon at gmail.com
Mon Jan 8 00:24:00 UTC 2007


On 1/7/07, David Härdeman <david at hardeman.nu> wrote:
> 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 found that my cam works much better with usleep(90000) rather
than 250, really dont know why but I often had to reload the dvb-s
card modules and restart the backend before I made that change, I
rarely have to do that now.

Andy

> >>  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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>


More information about the mythtv-dev mailing list