MythTV high CPU usage — solved!

I’ve been dealing with a very strange problem with my MythTV HTPC for a while now. Occasionally, for no good reason that I could see, both the frontend and backend processes would spike to 100% CPU utilization and hang out there until they were restarted. This caused the fans to spin up, which was annoying.

I had some time today to investigate this problem, and it turns out (at least so far) to be related to the UPnP feature. Read on for more about how I fixed it.

What Was Wrong

The problem was simple: some seemingly arbitrary amount of time after starting up, both the mythfrontend and mythbackend processes would each start taking up 100% of a CPU, and spinning their wheels (per strace) on a series of select() and ioctl() calls. This behavior would persist until the processes were restarted. It happened to the backend even if the frontend wasn’t running (I didn’t test the converse). Also, the HTPC bits still worked fine and played videos; it seemed like the CPU utilization was at a lower priority than actually doing useful work.

That said, it was still really annoying, and it had an actual impact in terms of excess heat and noise, along with power consumption. I sat down today to beat my head against it until something broke.

What Didn’t Work

I tried a lot of different things to figure out what might be causing this problem. I upgraded my HTPC to the recently-released 0.27 version of MythTV; I tried rebooting several times; I even sat with an strace running on the backend and frontend processes to see what happened when they wigged out. (That’s how I noticed the select() and ioctl() behavior.)

However, none of this investigation pointed me towards a real culprit.

What Did Work (at least so far)

I happened to stumble upon this post which indicated that turning off UPnP fixed his issue on both the front- and backend processes. That was an important find, because most of the other information I ran into only talked about one or the other process misbehaving.

I disabled UPnP on both processes, and they’ve been working great so far. This is a significant improvement from before; I could be pretty confident that the high CPU utilization would begin within ~10 minutes of the processes starting up, and without fail within ~30 minutes.

How To Make It Stick

Backend

I’m running Mythbuntu, so the underlying system is a Debian derivative using upstart. The mythtv-backend service isn’t actually written as an upstart job; instead, it uses the configuration file /etc/init/mythtv-backend.conf. I added “--noupnp” to that file:

[sourcecode language=”text” light=”true”] adam@mythtv:~$ diff -ub mythtv-backend.conf{.orig,} — mythtv-backend.conf.orig 2013-10-02 21:58:46.000000000 -0700 +++ mythtv-backend.conf 2013-10-02 21:58:16.000000000 -0700 @@ -27,5 +27,5 @@ script test -f /etc/default/locale && . /etc/default/locale || true – LANG=$LANG exec /usr/bin/mythbackend –syslog local7 –user mythtv –daemon + LANG=$LANG exec /usr/bin/mythbackend –syslog local7 –user mythtv –daemon –noupnp end script [/sourcecode]

and restarted the service, and that seems to have fixed things right up.

Frontend

Mythbuntu automatically runs the frontend process on session startup, so all I needed to do was change the startup file in ~/.config/autostart/mythtv.desktop:

[sourcecode language=”text” light=”true”] adam@mythtv:~/.config/autostart$ diff -ub mythtv.desktop* +++ mythtv.desktop.orig 2013-10-02 22:05:16.000000000 -0700 — mythtv.desktop 2013-10-02 22:05:29.000000000 -0700 @@ -2,7 +2,7 @@ Name=MythTV Frontend Comment=A frontend for all content on a mythtv-backend GenericName=MythTV Viewer -Exec=mythfrontend –service +Exec=mythfrontend –service –noupnp Type=Application Encoding=UTF-8 Icon=mythtv [/sourcecode]

This did the trick on the frontend side.

What I Learned

MythTV is ludicrously complicated. I didn’t even realize it had a UPnP feature, and that turned out to be what was causing all my trouble. On the plus side, the program guide in 0.27 is much more stable, so the day turns out not to have been a total waste.

Tags: ,

  1. xfr’s avatar

    I checked /usr/bin/mythfrontend and it said….

    echo "Please note: additional command line arguments will not be passed" echo " to mythfrontend when using --service" echo "Please set them in /etc/mythtv/session-settings instead"

    so your patch did not really disable upnp in the frontend…

  2. adamc’s avatar

    That’s interesting; it definitely has worked on my machine with only the change I described. I’ll look when I get home and see if my copy of mythfrontend has that note as well. Thanks for the note!

  3. Seán Ó Séaghdha’s avatar

    This appeared to work at first, but once again today I have mythbackend at 100% cpu. Maybe there are multiple causes and this was just one.

  4. Travis Kneale’s avatar

    Also to ad my findings on a intel GPU

    –noupnp fixed my backend but frountend was still haveing an issue.

    I changed my playback options from OpenGL to Slim(ffmpeg+xvid).

    Sitting at a load of 0.40 on a intel pentum 620. Thanks for the upnp hint.

  5. Ben’s avatar

    Cool – Just noticed this problem on my backend server today. I’m going to give this solution a shot.

  6. Martin’s avatar

    Cool, thanks, I have been battling with the 100% CPU issue for a year now on an Ubuntu 10.04 box, and still now on 14.04. I hardly ever noticed it, because the backend is running on a quad-core machine, still its wasting away way too much power.

    Really looking forward if disabling UPnP fixed the issue. Thanks for the hint!

  7. Martin’s avatar

    The –upnp didn’t fix it for me, but I finally found the reason (and can now life with it): the reason is the EPG scan that starts in the background, if tuners are idle.

  8. sndguru’s avatar

    Thank you very much, your fix has reduced my four processors from flat lining, and has honestly reduced the Watts draw of my server, saving me just short of $5 a month (That also not taking into account the 2 separate frontend’s that get turned and off during the day). Now to not think about how much I lost over the past 2 or 3 years while the fault has gone on for 🙁

Reply

Your email address will not be published.

Please copy the string wOWKlL to the field below: