[mythtv-users] MythTV 29.1 nVidia video jump hesitation with 5.15 kernel

[faginbagin]

On 1/24/2022 2:16 PM, Tom Dexter wrote:
> This is a tough one, and I tend to doubt anyone will have any ideas,
> but I figured I'd throw it out there:
>
> For reasons I won't get into, I'm still running MythTV 29.1. This is
> under Gentoo and the frontend is an x86 (32 bit) machine with a GT 430
> nVidia card, using nvidia-drivers-390.147, and using vdpau. Currently
> I have both the 5.10.93 and 5.15.16 Linux kernels installed. When I
> use the 5.15 kernel...and ONLY with that kernel...I'm getting odd
> video/audio hesitations when jumping forward or back, and only in
> MythTV. That is, I can't reproduce this in xine or mpv. This occurs
> both with TV records as well as h264 videos in browse mode reading
> from the local disk.
>
> Specifically, when I jump forward or back, there's a momentary
> hesitation before the audio kicks in, and during that short time, the
> video gets a little wonky, like it's slowing down for a second. In the
> 5.10 kernel everything's fine. Sort of really sucks. For now I'm just
> sticking with the 5.10 kernel. If anyone has any ideas I'd appreciate
> it. Thanks!
>
> Tom
>
This sounds like a kernel regression. If you're interested in a 
challenge that may or may not pay off in a solution, I think you'll need 
to do some kernel bisecting. By that I mean, first test if the problem 
exists in 5.13. If it does test 5.12, otherwise test 5.14. Once you know 
which kernel introduced the problem, then do a git bisect on that kernel 
branch. If you can identify an offending commit, you can report it to 
the appropriate kernel development arm and hope someone is interested in 
fixing it.

I actually had some luck in getting a problem fixed with an intel igp on 
a 32 bit laptop at the end of 2018. Here's the bugzilla link:
https://bugs.freedesktop.org/show_bug.cgi?id=107600
But that was three years ago.

I also had a problem with a radeon igp on a different 32 bit laptop. I 
went through the bisecting process and found a workaround with a kernel 
command line option as a result of tracking down the offending commit. 
So, I never needed to report what I considered a bug, because it was 
clear from mailing list and bugzilla discussions, that the kernel 
developers involved didn't think it was a bug, that the real problem was 
old buggy hardware.

I'm still on v29 because I've still got hardware that works and isn't 
supported by newer versions of mythtv or kernels. BTW, kernel 4.19 is 
under long term support and might be a more reliable kernel option for 
older hardware. Debian bullseye is on 5.10, and still supports 32 bit, 
so that should bode well for its use on gentoo with 32 bit hardware. 
I've got a circa 2002 pentium 4 desktop I use as a mail, web and file 
server. I've done some testing of it with bullseye. So far, so good.