[mythtv] Re: Tuner busy in consecutive recordings

[David Shirley]

on this topic,

i am recording :
channel 1 1900-2000 (encoder 1 chosen apparently)
channel 2 1900-2000 (encoder 2 chosen apparently)
channel 2 2000-2100 (encoder 1 chosen apparently)

shouldn't the third recording use encoder 2 as well? ie just continue?

see the problem i have with the above setup is that if channel 1 runs
overtime (like usual so i have a 1800 second extend in setup) then it
will be cut off at the end so that the encoder can swap to channel 2
for the 2000 show.

i hope this makes sense :)

cheers
dave


On 10/12/05, Isaac Richards <ijr at case.edu> 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)
>
> ?
>
> #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
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
>