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

Fri Jun 16 21:58:48 UTC 2017

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.