[mythtv] Re: Tuner busy in consecutive recordings
danielk at cuymedia.net
Wed Oct 12 14:56:48 UTC 2005
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:
> 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.
> 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...
More information about the mythtv-dev