[mythtv-users] 2005 laptop stutters after upgrade from 0.27 to 0.28

[faginbagin]

On 6/6/2017 6:39 PM, faginbagin wrote:
> Yep, I've still got a few old laptops that have been working quite well 
> as frontends. But one isn't performing quite as well with mythtv 0.28 
> and mythbuntu 16.04 as it is with mythtv 0.27 and mythbuntu 12.04. So, 
> I'm trying to understand why, and whether there's anything I can do to 
> get it to perform running 0.28 as well as it does running 0.27. The 
> laptop and the master backend have multiple boot partitions, so that's 
> how I switch back and forth between 0.27 and 0.28
> 
> I see slight but noticeable stuttering during panning scenes when I 
> playback standard definition H.264 video on 0.28 but not when I play 
> back the same video on 0.27. It's not CPU bound, the CPU hovers around 
> 30% to 35% on both versions and might be using a tad less CPU on 0.28 as 
> it does on 0.27.
> 
> The laptop is a Dell Inspiron B130 with an Intel Celeron M 1.5 GHz CPU 
> and an Intel Mobile 915GM/GMS/910GML Express Graphics Controller. The 
> display is 1280x800 resolution. It's configured to use the Slim playback 
> profile on both 0.27 and 0.28, as defined in the database migrated from 
> 0.27 to 0.28.
> 
> I have compared mythfrontend logs using -v general,playback at the 
> default info level. I can see no meaningful difference in the log 
> output. I've hesitated to try the debug level, for fear that might push 
> the CPU and/or disk to work too hard, although maybe that should be my 
> next step?
> 
> I have compared Xorg.0.log on both OSs, and only see slight differences 
> like version numbers, and a handful of different messages that I suspect 
> are due to logging changes in source and not meaningful.
> 
> FWIW, the laptop can play 720p and 1080i MPEG2 transport streams 
> smoothly in both 0.27 and 0.28. But it cannot play high definition H.264 
> content on either, where it's definitely CPU bound. I've also got a 
> couple of circa 2004 thinkpads with Pentium M CPUs and Radeon GPUs that 
> CAN handle the SD H.264 in both 0.27 and 0.28 environments. It's just 
> this Dell that's keeping me from cutting over to 0.28.
> 
> Has anyone else noticed a degradation in performance on older hardware 
> after upgrading?
> 
> Any suggestions on how to identify the cause, e.g. OS module, X driver 
> or mythtv?

This is my follow up to everyone who offered suggestions on getting my 
old laptop to function on 0.28/16.04 at least as well as it did on 
0.27/12.04. First a summary, then the gory details.

Summary:

I could not find a configuration that would allow 0.28 mythfrontend to 
work as well as 0.27 mythfrontend playing standard definition h264 
video. I think there's strong evidence that the problem is due to 
something that changed in the mythfrontend or libmyth* code, not in the 
OS, Xorg, or ffmpeg code that mythtv syncs with.

I found that mythtv 0.27 on mythbuntu 14.04 works as well as it did on 
12.04. So, in order to get security updates for a couple more years, I 
am upgrading all my machines running 12.04 to 14.04. Maybe this laptop 
will give up the ghost before I get new hardware that really needs a 
newer OS, Xorg or version of mythtv. Or I may set up a cross compile 
environment on another machine so I can do a git bisect and identify an 
offending commit. The laptop is too slow and doesn't have enough disk 
space to do that.

Details:

Mike Perkins suggestions:
* Check wiki articles:
- https://www.mythtv.org/wiki/User_Manual:JudderFree
(Seconded by Anthony Giggens)
Not sure this article can help since I'm using the laptop's built in 
display. xrandr reports:
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 4096 x 4096
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 
331mm x 207mm
    1280x800       60.0*+
    1024x768       60.0
    800x600        60.3     56.2
    640x480        59.9
VGA1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
As you can see, not much variation in refresh rates.
Gave it a try after RTC timer didn't help. Found that aspect ratios are 
messed up and all video is pillar boxed. As you can see from the above 
xrandr output, the display's native resolution is 1280x800, with an 
aspect ratio of 16x10, but the alternate supported resolutions are all 
4x3. I tried tinkering with aspect ratios during playback but could not 
find anything sane, or any way to use the full width of the display.

- https://www.mythtv.org/wiki/Frame_display_timing
The laptop was using usleep in both 0.27 and 0.28. Getting RTC to work 
sounded promising. I was really hoping this would do it, but it had no 
effect. Tried both 1024 and 2048 for max_user_freq. It's hard to see 
that going higher would help.

* Cut mythtv out, compare playback with vlc on 12.04 vs 16.04
If RTC doesn't help, this might provide more diagnostic info.
Played the troublesome SD h264 mp4 file on vlc. Looks fine on 16.04 with 
vlc 2.2.2 and CPU is comparable to mythfrontend (see below). That's 
using XVideo/xcb_xv video output, which I believe is comparable to 
mythfrontend's Slim profile. Also tried OpenGL GLX/xcb_glx video output, 
and found the CPU usage was about double the usage with XVideo output. 
Also looks fine on 14.04 with vlc 2.1.6 (I had replaced 12.04 by this 
time). Similar results WRT CPU usage, maybe 3-5 points lower. This seems 
to suggest the problem is changes from 0.27 to 0.28 in mythfrontend. 
Also suggests a possible workaround by configuring mythfrontend to use 
vlc to playback h264 content.

* Try a "complex" transcode on the local test file using ffmpeg on
both 12.04 and 16.04 to see if that shows a significant difference or
not (something to make the laptop sweat / work hard so small differences
might be more readily noticed).
I think the idea is to compare how fast the laptop can decode the video 
in 12.04 vs 16.04. Using mythffmpeg in both environments might provide 
some insight into changes from 0.27 to 0.28 in the slim playback 
profile's performance, since both mythffmpeg and mythfrontend use the 
same code. Between this and comparing playback with vlc, it could 
identify whether the problem is in mythtv or the O/S and/or Xorg 
drivers. I decided to use mythffplay, since the problem is one of 
decoding and display, not transcoding.
0.27/14.04, based on ffplay/ffmpeg 1.2.7. Works well, CPU is comparable 
to mythfrontend with Slim profile.
0.28/16.04, based on ffplay/ffmpeg 3.0. Works well, CPU is comparable to 
mythfrontend with Slim profile.
I think this is even stronger evidence than the vlc test that the 
problem is not in the OS, Xorg, drivers, or in the port of ffmpeg to 
mythtv, and narrows it down to the mythfrontend or libmyth* code that 
supports mythfrontend.

My idea:
Try mythbuntu 14.04. It won't get me to mythtv 0.28, but it will give me 
a couple more years of long term support and security updates from 
Ubuntu. Seems to work as well as 12.04 and eliminates 2 years of OS and 
Xorg changes as possible culprits. Only drawback is a slight increase in 
memory usage, see stats for frames decoded/free suggestion.

Peter Bennett suggestions:
- Try an OpenGL playback profile. This is easy to test.
On 12.04 tried glxgears, it reported an average around 15fps, well below 
the display's 60Hz refresh rate.
On 16.04 tried glxgears, it reported an average around 48fps, much 
closer to the display's 60Hz refresh rate.
On 0.28/16.04 using "OpenGL Slim" playback profile pushes CPU usage up 
about 15 percentage points. That's OK for the troublesome SD h264 video, 
which plays more smoothly at around 50%. But HD mpeg2 content that plays 
OK with the Slim profile, using 80-90% CPU, is now CPU bound and 
stutters badly, much worse than the slight stuttering it fixes for SD 
h264 video. That's true for both 720p and 1080i with the default One 
Field deinterlacer as well as deinterlacing set to None. So using an 
OpenGL profile fixes an annoying problem with one type of content but 
creates more serious problems for other content.

- Could be https://code.mythtv.org/trac/ticket/12907
This ticket talks about problems playing 60fps video. It doesn't say 
what encoding or resolution. The laptop can play 720p mpeg2 60fps video 
running 0.28/16.04. My problem is with h264 encoding, standard 
definition resolution, with an average frame rate less than 25fps.

Stuart Auchterlonie suggestion:
Monitor playback OSD frames decoded/free figures, should stay as high as 
possible. I had used this to monitor CPU usage, but not frames decoded/free.
0.27/12.04 slim - consistently 28/1, and CPU approx 30-40%, briefly up 
to 43% during panning.
top stats mythfrontend mem 14.8% Xorg 2.4%
0.27/14.04 slim - consistently 28/1, and CPU approx 30-40%, briefly up 
to 43% during panning.
top stats mythfrontend mem 15.4% Xorg 2.6%
0.28/16.04 slim - consistently 28/1, CPU similar to 0.27/12.04.
top stats mythfrontend mem 23.5% Xorg 3.3%
0.28/16.04 opengl - consistently 28/1, CPU increased to around 50%
top stats mythfrontend mem 23.2% Xorg 2.0%

Brian Murrel suggestion:
Replace mythfrontend with Kodi.
I think this would involve a steep learning curve, not just for me, but 
for my family. I would consider this a last choice.

Again, many thanks for everyone's suggestions. I welcome any other 
ideas, thoughts, etc.