[mythtv-users] Hard frontend crash with vaapi on Ubuntu 20.04 and Mythtv 31

Stephen Worthington stephen_agent at jsw.gen.nz
Tue Jun 1 14:36:53 UTC 2021

On Wed, 2 Jun 2021 02:16:28 +1200, you wrote:

>> On 6/1/21 7:05 AM, OpenMedia Support wrote:
>>>> On 6/1/21 3:38 AM, OpenMedia Support wrote:
>>>>> I'm running an Intel N3150 based NUC as a dedicated frontend for
>>>>> MythTV
>>>>> and it keep getting hard crashes during video playback with VAAPI. Id
>>>>> appreciate some guidance on how to best debug the problem.
>>>>> Hardware - Gigabyte Brix Intel N3150 / 4GB Ram / 120GB SSD
>>>>> OS - Ubuntu 20.04 LTS - regularly patched
>>>>> MythTV Backend - on different hardware with DVB-T and DVB-S cards
>>>>> MythTV Frontend - Lastest version from the PPA -
>>>>> http://ppa.launchpad.net/mythbuntu/31/ubuntu
>>>>> Video playback currently uses a custom VAAPI profile, but the out of
>>>>> the
>>>>> box VAAPI profile also has issues. It appears to occur when playing
>>>>> H.264
>>>>> based content. Our DVB-T FTA service is H.264 for both HD and SD
>>>>> material.
>>>>> It can occur when we're simply watching a show, and the video / audio
>>>>> freezes and I need to hard-reset the Brix hardware.
>>>>> I've configured for
>>>>>    - max_cpus = 3
>>>>>    - deinterlacer - low:shader:driver
>>>>>    - decoder - vaapi
>>>>>    - videorender - opengl-hw
>>>>>    - skiploop - 0
>>>>> I'll try and reproduce with "-v playback" enabled but at present there
>>>>> is
>>>>> nothing obvious in the frontend or system logs when the crash occurs.
>>>>> I'd really appreciate it if anyone else seen similar issues and could
>>>>> provide guidance.
>>>> I have a NUC i7-1165G7 and it has Iris graphics.  I can't get VAAPI
>>>> to
>>>> work at all. I have to use OpenGL low quality deinterlacing. When I use
>>>> VAAPI it crashes with code 139. I can't run higher than low
>>>> deinterlacing because the pictures tears about 10% from the top of the
>>>> screen.
>>>> Luckily, I didn't buy the $800 NUC as a mythtv frontend only. Iris GFX
>>>> and Mythtv aren't a good solution for sure.
>>> The N3150 Brix was relatively cheap and generally makes quite a nice
>>> front
>>> end, and now it has an SSD is effectively silent.
>>> Just had a fresh hard crash with "-v playback" and all I can see is the
>>> following as I had an SSH session tailing the frontend logs.
>>> Jun  1 21:49:37 mythfe1 mythfrontend.real: mythfrontend[1900]: I
>> Are you able to get into ssh to kill the frontend when it locks up? I
>> would say the thing to do is enable core files by setting the limit and
>> disabling Ubuntu crash logging, then when it happens run kill SIGQUIT to
>> create a core dump which can be analyzed to see where the hang occurred.
>Afraid not. This is a hard crash and I loose my SSH sessions. I've been
>running a couple of sessions to tail the mythfrontend and system logs and
>they become responsive until I reboot the hardware.

Have you tried using the magic keys to see if you can get the
filesystem buffers to flush before rebooting?  Sometimes you can get
some log information that way.

In /etc/sysctl.conf, put:


to allow all the magic keys.  Run "sysctl --system" to reload the
sysctl.conf settings, or reboot.  Then when the next lockup happens,
hold down the Alt and SysReq keys, then with both down type this


If your keyboard does not have a SysReq key marked, it is also usually
the PrntScrn key.

See here for what each keystroke does:


The S and U are the critical ones - they sync and unmount the

Your problem has the same characteristics as what I had when I first
installed my Nvidia GT1030 card.  In my case, it was an Nvidia driver
bug and it became much less common with a driver update in the same
series, and went away completely with a major driver update.

More information about the mythtv-users mailing list