[mythtv] 34ad18e0c951a289e5bbebea065b17359c1bfc1d causes deadlock on BE when tuning takes longer than 10sec

John P Poet jppoet at gmail.com
Tue Feb 28 00:18:46 UTC 2017


On Mon, Feb 27, 2017 at 2:15 PM Piotr Oniszczuk <piotr.oniszczuk at gmail.com>
wrote:

>
> > Wiadomość napisana przez John P Poet <jppoet at gmail.com> w dniu
> 26.02.2017, o godz. 23:08:
> >
> >
> >
> > If you change the timer check from 10000 to 60000, does that 'fix' it
> for you?
> >
> >     if (ringBufferCheckTimer.isRunning() &&
> >         ringBufferCheckTimer.elapsed() > 60000)
> >     {
> >         LOG(VB_RECORD, LOG_WARNING, LOC + "It is has been over 60
> seconds "
> >             "since we've checked for a ringbuffer switch.");
> >         CheckForRingBufferSwitch();
> >     }
> >
> > If so, that would prove your hypothesis.  However, I only see one place
> where nextRingBuffer is not protected by a mutex and that is in the
> destructor, so I am not seeing where this would cause a deadlock.
> >
> > John
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> > http://wiki.mythtv.org/Mailing_List_etiquette
> > MythTV Forums: https://forum.mythtv.org
>
> John,
> Yes. I can confirm. 60sec fixes issue.
> After change to 60sec I can’t trigger deadlock within 100 channel changes.
> With 10sec time, deadlock was easy to trigger with 5..10 channel changes.
>

Okay, thanks Piotr.  For now, I will change it to 60 seconds, but it sounds
like I need to examine your BT in detail, and see if I can spot where the
deadlock is happening.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20170228/62ee3807/attachment.html>


More information about the mythtv-dev mailing list