[mythtv-users] Fwd: Re: Fwd: Re: Mythfrontend freezing and VDPAU?

[Allen Edwards]

On Mon, Mar 2, 2020 at 7:15 AM John <jksjdevelop at gmail.com> wrote:

>
> On 02/03/2020 14:41, Allen Edwards wrote:
>
>
>
> On Mon, Mar 2, 2020 at 2:19 AM John <jksjdevelop at gmail.com> wrote:
>
>>
>>
>> On 02/03/2020 01:48, Allen Edwards wrote:
>>
>> I continue my search for why my mythfrontend is locking up. As I have
>> said, the real bother is that it basically requires a restart of the
>> computer to clear up the problem as I have discussed previously.
>>
>> The error I am seeing in the log is this
>> *Decoder timed out waiting for free video buffers*
>>
>> What I have found is that several others have had this problem and have
>> isolated it to VDPAU with an interlaced source. We had a lock up again last
>> night and sure enough the source was 1080i and the output is 1080p.
>>
>> There does not seem to be a solution online that I can find.
>>
>> Here is one thread https://forum.mythtv.org/viewtopic.php?t=2735
>> Here is another
>> https://devtalk.nvidia.com/default/topic/1037255/linux/mythtv-errors-lockups-with-vdpau-and-340-or-390-drivers-/
>>
>> My question is, am I using the right driver and video configuration? Next
>> question, what should I use if VDPAU is unacceptable?
>>
>> I am running Mythbuntu
>> Ubuntu 16.04.1 LTS
>> MythTV Version : v0.28.2-6-g9031599
>> MythTV Branch : fixes/0.28
>> AMD Athlon(tm) 64 X2 Dual Core Processor 5400+
>> 6G memory
>> GeForce GTX 750Ti
>> nvidia 390 driver
>> VDPAU High Quality
>>
>> Allen
>>
>> _______________________________________________
>> mythtv-users mailing listmythtv-users at mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>> I have found that using High Quality software decoding to be more
>> reliable and tolerates faults in the broadcast stream. The cpu load is only
>> moderate - try it.
>>
>> By the way this issue is still present in V31 so upgrading will not help.
>>
>
> Thanks so much for the confirmation of the issue. I have been wondering
> about using software but wasn't sure my CPU could handle it. What specific
> settings do you recommend?
>
> Allen
>
> _______________________________________________
> mythtv-users mailing listmythtv-users at mythtv.orghttp://lists.mythtv.org/mailman/listinfo/mythtv-usershttp://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
> I am on ver 31 using Opengl High Quality and cant remember the exact
> settings for V28 but I think there was a High Quality choice in
> Setup>Video>Playback>Current Video Playback Profile
>
> You should get ffmpeg decoding and if I remember correctly vdpau double
> de-interlacer.
>
> That config never failed for me on a combined Intel Haswell front and
> backend with Nvidia graphics.
>
> Note i still get judder with software decoding if there are background
> tasks running so avoid that.
>

I tried "High Quality" and so far it looks good picture quality wise.

I took a look at the CPU load using top and I find that strange.
Mythfrontend with VDPAU runs about 9% and with High Quality about 29%. That
seems fine.
Xorg is what I find strange. With VDPAU it runs about 2% and with High
Quality it runs all over the place. I have seen as low as 6% and as high as
96%

I guess this is OK as long as nothing is pinned at 100% and I see that
mythcomflag is able to get in there and it only uses left overs so I guess
all is good.

If there was just an easy way to restore operation after a lock up like
there was when I was running Mythbuntu 8 we could live with the occasional
lock-ups which happen about once a month. I modified several things so that
CTRL-ALT-BS will restart X but it does not work when mythfrontend is locked
up. Basically, only "shutdown now -r" works in that case.

Thanks for the help. We will try High Quality and see how it goes.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20200302/758be47c/attachment.htm>