0.27 mythfrontend.re process takes 100% cpu

[eric.koester@…]

Mythtv Version: Mythbuntu 12.04LTS 64-bit with the myth 0.27.4 (v0.27.4-30-g3b43903) (myth 0.27 fix repo branch).

Hardware: BIOSTAR NF4Ultra NF4 Ultra-A9A motherboard, AMD 4000+, 64x, Dual Core, 2GB RAM, 2TB WD SATA hard drive, Nvidia GT220 card (with 1GB DDR2 RAM), PCI Gigabit Ethernet card with Realtek Semiconductor Co., Ltd. RTL8169 PCI Gigabit Ethernet Controller (rev 10)

I'm using the default theme in Mythbuntu 12.04: MythCenter? Wide. I usually take updates from the repo once per month, so changes in the system behaviour usually occur after one of these updates.

November 5, 2014: the mythtvfrontend.re process started hogging 100% of one of the CPU cores. When this first started happening in November, the Mythtv frontend becomes unresponsive to the IR Remote AND the pc keyboard. To regain control, I used the pc keyboard and do an ALT-F1 to get to a terminal screen, and check the "top" command. Then, I see the mythfrontend.re process taking up over 100% of the CPU. I found that if I did a "sudo pkill mythrontend" then "sudo pkill mythfrontend.re", I am able to regain control of the GUI interface. At that point, I restart the Mythtv Frontend application from the GUI interface and it works normally, for approximately 15-60 minutes.

December 2014: The behaviour changed a little. mythfrontend.re still hogged 100% of one of the CPU cores, but the keyboard and IR remote still worked to control it. The main effect of having 100% of one CPU core occupied is slow UI response times and missed/shipped characters/numbers during the run of the IR blaster channel change script, which sends IR channel change codes to the satellite receiver. I found that I can run the channel change script when the mythfrontend is not running, and all IR characters are recognized by the satellite receiver. When the mythfrontend is running and taking 100% of a CPU core, not all the IR characters are sent to the satellite receiver. Often channel 355 gets sent as channel 5 (clearly the 3 was missent or never sent).

January 2015: Current behavior is the same as in December 2014.

Current Workaround: Exit mythfrontend at the end of every program viewing session, and only run the mythfrontend when I want to view recorded programs. By doing this, the IR blaster channel change script executes normally, without missed digits.

I plan to submit whatever information is helpful. I suspect that mythfrontend.log and mythbackend.log files showing events around the time of a CPU core takeover are most desirable?

[Eric Koester <eric.koester@…>]

mythfrontend.log

[Eric Koester <eric.koester@…>]

I just attached the mythfrontend.log file from toady. This morning I started the mythfrontend and waited for a CPU core to go to 100%+ usage. It went to 101% usage sometime after 11:00:00 in the log for Jan 24.

[Eric Koester <eric.koester@…>]

mythbackend.log file

[stuartm]

We're aware of this issue, the current suspect seems to be the periodic background process which looks for theme updates. You can disable this check by pressing MENU when in the theme selection screen.

[Eric Koester <eric.koester@…>]

I tried disabling the theme updates setting. That did not work. mythfrontend.re still takes over after some period of time.

The only workaround that works is exiting the Mythtv Frontend before I walk away from the machine.

If I don't exit the Mythtv Frontend, then the channel change function (via the serial IR blaster) doesn't occur correctly and the satellite receiver will not be on the correct channel for recordings.

[griesbac@…]

I have the same issues as reported already in this thread. The issues started about the same time in November, and continue today. I use the current Mythbuntu theme, which is currently 28.20. However, I do not think this is theme related.

I have also tried disabling the theme updates setting, but mythfrontend.re still takes over 100% CPU at some point.

I have not been able to pinpoint a cause, sometimes it takes days and sometimes it's hours, but eventually a mythfrontend.re process will increase to 100% CPU on my machine.

Luckily, I have a multi-core machine, so I still have full control of the frontend after it ramps to 100% CPU.

I have also tried leaving the frontend sit on a different menu than the initial (main) menu, but this does not fix the problem either.

As Eric has said, only shutting down the frontend between sessions seems to be the only workaround so far, and this is less than ideal.

I can provide my system specs and logs, but I doubt they will add any information beyond what Eric has already provided. My log artifacts seem identical.

[Jonathan <jonathan@…>]

I had this problem very consistently, and was able to produce detailed error logs (Hi paulh). I currently work around it by leaving my system on the Status Screen (accessible with a jump point programmed into my remote as part of the power toggle sequence). The system has never run away when in this state.

If the frontend thread runs away while a commercial detection job is running, my little dual-core Zacate processor overheats, panics, halts, and reboots.

Earlier it looked like the problem happened in the loop in lines 273-346 of ​https://code.mythtv.org/doxygen/mythdownloadmanager_8cpp_source.html Maybe we can add a sleep(1) between lines 274 and 275 just so this doesn't crash user systems? Adding a delay between download requests is reasonable practice anyway. I don't have a suitable development environment but I'd be pleased to run a version with more detailed logging inserted into this loop, to try to catch the condition that triggers the runaway.

[Paul Harrison <pharrison@…>]

In 7e0441c38166ded77b3a1b3a869e40a5af389fa0/mythtv:

MythDownloadManager?: add some logging to try to track down the 100% cpu bug

This also allows the theme checker to be run once a minute rather than the
usual once an hour to try to trigger the bug quicker. Setting the
MYTHTV_DEBUGMDM environment variable will run the checker every minute.

So for master use :-
MYTHTV_DEBUGMDM="1" mythfrontend -v file:debug

Refs #12356

[Paul Harrison <pharrison@…>]

In 6b7397699b5a356ecfb78497a26094b0fbbd334e/mythtv:

MythDownloadManager?: add some logging to try to track down the 100% cpu bug

This also allows the theme checker to be run once a minute rather than the
usual once an hour to try to trigger the bug quicker. Setting the
MYTHTV_DEBUGMDM environment variable will run the checker every minute.

So for 0.27.4-fixes use :-
MYTHTV_DEBUGMDM="1" mythfrontend -v file --loglevel=debug

Refs #12356

(cherry picked from commit 7e0441c38166ded77b3a1b3a869e40a5af389fa0)

[paulh]

I tried for a couple of days to reproduce this but couldn't no matter what I did. I've just added some extra debugging to hopefully throw some light on what is happening so if someone who can reproduce this can get some new logs.

Just be careful if you direct the logs to a file and the download thread does run away you could end up with some very large log files!

If you set the MYTHTV_DEBUGMDM environment variable you should be able to trigger the problem after a few minutes if you leave the frontend on the main menu to trigger the theme updater every minute.

[Paul Harrison <pharrison@…>]

In 58694eb41a528467c7d54b85c211479204ee24ac/mythtv:

MythDownloadManager?: put the lock around m_downloadInfos when removing a url

Also log an error if we fail to remove a download url from m_downloadInfos after
a download completes.

Refs #12356

[Paul Harrison <pharrison@…>]

In d620cb9e1b19a5fa1e693a91d9ea6271e03640b4/mythtv:

MythDownloadManager?: fix a bug when downloading URL's with percent encoding

This avoids converting a url to a QUrl only to later use its toString() method
which was causing problems with percent encoded URL's not being removed from the
download queue because we ended up comparing a human readable URL with a percent
encoded one.

Refs #12356

[Paul Harrison <pharrison@…>]

In e7af3a08c6b6f385d9d4b93948c812a394110a4a/mythtv:

MythDownloadManager?: put the lock around m_downloadInfos when removing a url

Also log an error if we fail to remove a download url from m_downloadInfos after
a download completes.

Refs #12356

(cherry picked from commit 58694eb41a528467c7d54b85c211479204ee24ac)

[Paul Harrison <pharrison@…>]

In 8fd277bb1ecab938e57059dc9472b6f922d5fca7/mythtv:

MythDownloadManager?: fix a bug when downloading URL's with percent encoding

This avoids converting a url to a QUrl only to later use its toString() method
which was causing problems with percent encoded URL's not being removed from the
download queue because we ended up comparing a human readable URL with a percent
encoded one.

Refs #12356

(cherry picked from commit d620cb9e1b19a5fa1e693a91d9ea6271e03640b4)

[paulh]

Reported to be fixed in the forums. Thanks to nouglywires for testing.

[neutron68@…]

Which files are part of the fix? The changed files will be version 0.27.5?

I'm just trying to figure out how I can tell when these changes get included in the Mythbuntu 0.27 updates. I just pulled down some Mythbuntu updates and saw a bunch of 0.27.4 versions fly up the screen.

[Jonathan <jonathan@…>]

Replying to neutron68@…:

Which files are part of the fix? The changed files will be version 0.27.5?

I'm just trying to figure out how I can tell when these changes get included in the Mythbuntu 0.27 updates. I just pulled down some Mythbuntu updates and saw a bunch of 0.27.4 versions fly up the screen.

Fixed in v0.27.4-64-g8fd277b - thanks again!

[neutron68@…]

Thanks for your work fixing this.

Which files are part of the fix?

[Stuart Auchterlonie]

Replying to neutron68@…:

Thanks for your work fixing this.

Which files are part of the fix?

They are in the links contained within this ticket. For reference, see ​https://code.mythtv.org/trac/changeset/e7af3a08c6b6f385d9d4b93948c812a394110a4a/mythtv

and you may well need the prior change ​https://code.mythtv.org/trac/changeset/6b7397699b5a356ecfb78497a26094b0fbbd334e/mythtv