[mythtv] Re: [mythtv-commits] Re: Ticket #743: Fix "program not found in PAT" problem.

[Stuart Auchterlonie]

On Sat, Dec 03, 2005 at 12:07:18PM -0500, Daniel Kristjansson wrote:
> On Sat, 2005-12-03 at 00:37 +0000, Stuart Auchterlonie wrote:
> > On Fri, Dec 02, 2005 at 10:51:06PM +0000, Stuart Auchterlonie wrote:
> > My suspicion is that the data has been read off the demux,
> > but due to whatever reason hasn't been processed, when a channel
> > change goes through, leading to the race condition.
> 
> I'm assuming you are using Linux 2.6.12 or later, if not upgrade 
> and see if the problem goes away. The detection of the end of tuning
> is known to not work on some pre-2.6.12 drivers. The problem is
> that the event interface wasn't well defined so some drivers
> implemented something that worked in practice, and others did not.
> The code in MythTV tries to work with the old broken interface
> in dvbchannel.cpp's wait_for_backend() and according to what one
> of the DVB guys told us should always work with the drivers
> included with Linux 2.6.12+. There is a more detailed explanation
> in the doxygen documentation for the function.

Yes 2.6.13.4 + linux-dvb cvs from about 1-2 months ago.

> 
> > Am I right in saying that the tuning process and monitoring are
> > done in separate threads? Since, AFAIK the signalmonitor runs in
> > it's own thread, as does the eit crawler.
> Yes, separate threads. The EIT crawler thread doesn't do the tuning
> though, the recorder's tuning thread does it. This was done to avoid
> race conditions. :)
> 

So what happens in the case where the kernel has already read
stuff from the card for us, but we haven't yet read the data from
the kernel? Or does the kernel copy direct to userspace?

My line of thinking here is old data in the kernel buffers that
isn't cleaned out when we start looking for the new data.


Also, does the recorder run in a different thread to the sigmon?
If so we might have to look at those interactions....


Stuart