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

[Piotr Oniszczuk]

> 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.