<div dir="ltr">What I do with a crashing frontend is to run it interactively in a gdb session. If the failure is in mythfrontend then gdb catches it. If the failure is due to a kernel crash, like in the driver, then this does not work and the only option I see then is just trying all different driver versions that you can find.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Jun 2021 at 17:52, OpenMedia Support <<a href="mailto:support@openmedia.co.nz">support@openmedia.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Wed, 2 Jun 2021 02:16:28 +1200, you wrote:<br>
><br>
>>><br>
>>> On 6/1/21 7:05 AM, OpenMedia Support wrote:<br>
>>>>> On 6/1/21 3:38 AM, OpenMedia Support wrote:<br>
>>>>>> I'm running an Intel N3150 based NUC as a dedicated frontend for<br>
>>>>>> MythTV<br>
>>>>>> and it keep getting hard crashes during video playback with VAAPI.<br>
>>>>>> Id<br>
>>>>>> appreciate some guidance on how to best debug the problem.<br>
>>>>>><br>
>>>>>> Hardware - Gigabyte Brix Intel N3150 / 4GB Ram / 120GB SSD<br>
>>>>>><br>
>>>>>> OS - Ubuntu 20.04 LTS - regularly patched<br>
>>>>>><br>
>>>>>> MythTV Backend - on different hardware with DVB-T and DVB-S cards<br>
>>>>>><br>
>>>>>> MythTV Frontend - Lastest version from the PPA -<br>
>>>>>> <a href="http://ppa.launchpad.net/mythbuntu/31/ubuntu" rel="noreferrer" target="_blank">http://ppa.launchpad.net/mythbuntu/31/ubuntu</a><br>
>>>>>><br>
>>>>>> Video playback currently uses a custom VAAPI profile, but the out of<br>
>>>>>> the<br>
>>>>>> box VAAPI profile also has issues. It appears to occur when playing<br>
>>>>>> H.264<br>
>>>>>> based content. Our DVB-T FTA service is H.264 for both HD and SD<br>
>>>>>> material.<br>
>>>>>> It can occur when we're simply watching a show, and the video /<br>
>>>>>> audio<br>
>>>>>> freezes and I need to hard-reset the Brix hardware.<br>
>>>>>><br>
>>>>>> I've configured for<br>
>>>>>>    - max_cpus = 3<br>
>>>>>>    - deinterlacer - low:shader:driver<br>
>>>>>>    - decoder - vaapi<br>
>>>>>>    - videorender - opengl-hw<br>
>>>>>>    - skiploop - 0<br>
>>>>>><br>
>>>>>> I'll try and reproduce with "-v playback" enabled but at present<br>
>>>>>> there<br>
>>>>>> is<br>
>>>>>> nothing obvious in the frontend or system logs when the crash<br>
>>>>>> occurs.<br>
>>>>>><br>
>>>>>> I'd really appreciate it if anyone else seen similar issues and<br>
>>>>>> could<br>
>>>>>> provide guidance.<br>
>>>>><br>
>>>>> I have a NUC i7-1165G7 and it has Iris graphics.  I can't get<br>
>>>>> VAAPI<br>
>>>>> to<br>
>>>>> work at all. I have to use OpenGL low quality deinterlacing. When I<br>
>>>>> use<br>
>>>>> VAAPI it crashes with code 139. I can't run higher than low<br>
>>>>> deinterlacing because the pictures tears about 10% from the top of<br>
>>>>> the<br>
>>>>> screen.<br>
>>>>><br>
>>>>> Luckily, I didn't buy the $800 NUC as a mythtv frontend only. Iris<br>
>>>>> GFX<br>
>>>>> and Mythtv aren't a good solution for sure.<br>
>>>>><br>
>>>> The N3150 Brix was relatively cheap and generally makes quite a nice<br>
>>>> front<br>
>>>> end, and now it has an SSD is effectively silent.<br>
>>>><br>
>>>> Just had a fresh hard crash with "-v playback" and all I can see is<br>
>>>> the<br>
>>>> following as I had an SSH session tailing the frontend logs.<br>
>>>><br>
>>>> Jun  1 21:49:37 mythfe1 mythfrontend.real: mythfrontend[1900]: I<br>
>>><br>
>>> Are you able to get into ssh to kill the frontend when it locks up? I<br>
>>> would say the thing to do is enable core files by setting the limit and<br>
>>> disabling Ubuntu crash logging, then when it happens run kill SIGQUIT<br>
>>> to<br>
>>> create a core dump which can be analyzed to see where the hang<br>
>>> occurred.<br>
>><br>
>>Afraid not. This is a hard crash and I loose my SSH sessions. I've been<br>
>>running a couple of sessions to tail the mythfrontend and system logs and<br>
>>they become responsive until I reboot the hardware.<br>
><br>
> Have you tried using the magic keys to see if you can get the<br>
> filesystem buffers to flush before rebooting?  Sometimes you can get<br>
> some log information that way.<br>
><br>
> In /etc/sysctl.conf, put:<br>
><br>
> kernel.sysrq=1<br>
><br>
> to allow all the magic keys.  Run "sysctl --system" to reload the<br>
> sysctl.conf settings, or reboot.  Then when the next lockup happens,<br>
> hold down the Alt and SysReq keys, then with both down type this<br>
> sequence:<br>
><br>
> REISUB<br>
><br>
> If your keyboard does not have a SysReq key marked, it is also usually<br>
> the PrntScrn key.<br>
><br>
> See here for what each keystroke does:<br>
><br>
> <a href="https://en.wikipedia.org/wiki/Magic_SysRq_key" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Magic_SysRq_key</a><br>
><br>
> The S and U are the critical ones - they sync and unmount the<br>
> filesystems.<br>
><br>
> Your problem has the same characteristics as what I had when I first<br>
> installed my Nvidia GT1030 card.  In my case, it was an Nvidia driver<br>
> bug and it became much less common with a driver update in the same<br>
> series, and went away completely with a major driver update.<br>
<br>
Thanks for the tip. I've enabled the setting.<br>
<br>
I've also enabled the HWE kernel and switched from 5.4.0.73.76 to<br>
5.8.0.53.60 to see if that will help<br>
<br>
<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</blockquote></div>