[mythtv] Re: Tuner busy in consecutive recordings

[Isaac Richards]

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)

?

#2:

There is a race condition here:

        if (doSleep && tuningRequests.empty() && !changeState)
        {
            triggerEventSleep.wakeAll();
            lock.mutex()->unlock();
            sched_yield();
-->possible badness
            triggerEventSleep.wakeAll();
            triggerEventLoop.wait(1000 /* ms */);
            lock.mutex()->lock();
        }

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

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.

Isaac