[mythtv] Re: Tuner busy in consecutive recordings

[Daniel Kristjansson]

On Wed, 2005-10-12 at 03:47 -0400, Isaac Richards wrote:
> On Wednesday 12 October 2005 01:22 am, Isaac Richards wrote:
> > On Wednesday 12 October 2005 12:37 am, David Engel wrote:
> > > On Wed, Oct 12, 2005 at 08:26:39AM +1000, David Griffith wrote:
> > > > I've updated my box to the latest SVN yesterday, and last night a show
> > > > that was due to be recorded directly after another show failed to
> > > > record, with the message in the "previously recorded" listing of "tuner
> > > > busy". This is off my bttv capture card - I've got a DVB-T card as
> > > > well, but this station is analog only.
> > >
> > > I had an rsTunerBusy case again this evening too.  Daniel, can you
> > > look at this some more?
> >
> > I'm leaning towards a race condition in the
> > triggerEventLoop/triggerEventSleep stuff, myself.
> 
> Think I got it.  Two bugs:
> 
> #1:
> The main event loop is sleeping on this condition:
>         if (doSleep && tuningRequests.empty())
> Shouldn't it be:
>         if (doSleep && tuningRequests.empty() && !changeState)
> 
> ?
It should be, but this wasn't the problem.
doSleep will be false if changeState is true in this loop.


> #2:
> where WaitForEventThreadSleep could possibly get woken up before the event 
> loop had even run.  WaitForEventThreadSleep is written in such a way that if 
> it gets woken up, it'll just return without ensuring that the work it was 
> waiting on is actually done..
This was probably the problem.

> I think I've got both fixed properly, but it might be easier to change the 
> stateChangeLock to be a non-recursive mutex so that we can use the other 
> version of wait.
If this fix doesn't do it, I'll make the conversion. It is mostly
just ChangeState() and [Set|Clear]Flags that have to be changed,
but I'll have to review all instances of recursion in TVRec...

-- Daniel