[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