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