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

Sat Jun 17 18:07:13 UTC 2017

On 6/16/2017 5:58 PM, Jay Foster wrote:
> On 6/16/2017 2:52 PM, faginbagin wrote:
>> 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.
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
> Did you try 0.28 on 14.04?  That is an available supported option AFAIK.

Hi Jay,

Thanks for the suggestion, I'll keep it in mind, although I'm not very 
hopeful it will help this laptop. I think the mythffplay test strongly 
suggests the problem lies in mythfrontend/libmyth* code.