High CPU usage in mythbackend

[mythtv@…]

While watching some recently-recorded shows, I found that they hadn't been commflagged. When I checked, the job queue had several commflagging jobs piled up. One of them (last night's episode (recorded in HD, if it matters) of Las Vegas) had been running since some time yesterday, but it wasn't using much CPU. I killed it and let it move on to the next job.

A short time later, I noticed that mythbackend was running with an abnormally high load. It's just recording from a PVR-350 as I write this, but it's taking 93-95% of the processor's time as I write this. The current load average (with mythbackend, mythcommflag, and Firefox being the main running processes) is hovering around 3.9-4.0. My Mythbox is an Athlon 64 3700 with 2 GB of RAM, so the swap has barely been touched since startup.

Relevant version numbers (everything was built from Gentoo ebuilds):

• mythtv-0.20_p11626
• ivtv-0.8.1
• libdvb-0.5.5.1-r2
• gentoo-sources-2.6.18-r3 (this is the kernel)
• nvidia-drivers-1.0.9629 (but this shouldn't affect a backend problem)

The recording devices are a PVR350 and an A180.

Now that the last recording is complete, the usage by mythbackend has gone to nearly 100% and the mythcommflag job that should be running is at 0%. After restarting mythbackend, mythcommflag is finally able to get some "quality time" with the processor. Load average is now down below 1.0, even with a couple of commflag jobs running simultaneously.

The only info in the system log pertaining to MythTV is a couple of mythfilldatabase segfaults, but that would be a separate problem.

[Rob Smith]

I also am having this issue

my system stats

• ivtv 0.7.1
• Vanilla sources (kernel.org sources) 2.6.17.3 (PREEMPT)
• mythtv 0.20 fixes rev 12288

[Rob Smith]

Small update on what's going on with mine

When I delete something with allow re-record, mythbackend jumps to 100%

about 30 seconds later, mythfrontend pops up a window saying it lost communication with the backend

frontend log

2007-01-01 19:56:30.346 MythSocket(8328258:17): readStringList: Error, timeout.
2007-01-01 19:56:30.346 Connection to backend server lost
2007-01-01 19:56:30.347 Connecting to backend server: 192.168.1.3:6543 (try 1 of 5)
2007-01-01 19:56:30.348 Using protocol version 31
2007-01-01 19:56:30.349 MythSocket(8d09268:17): writeStringList: Error, invalid string list.
2007-01-01 19:57:00.349 MythSocket(8d09268:17): readStringList: Error, timeout.
2007-01-01 19:57:00.349 Reconnection to backend server failed
ASSERT: "i <= nodes" in /usr/qt/3/include/qvaluelist.h (373)

backend log

2007-01-01 19:56:59.813 Scheduled 1318 items in 60.5 = 0.00 match + 60.48 place
2007-01-01 19:56:59.815 MythSocket(8197ee0:-1): writeStringList: Error, socket went unconnected.
2007-01-01 19:56:59.820 scheduler: Scheduled items: Scheduled 1318 items in 60.5 = 0.00 match + 60.48 place
2007-01-01 19:56:59.821 Reschedule requested for id 0.
2007-01-01 19:57:59.630 Scheduled 1318 items in 59.8 = 0.00 match + 59.81 place
2007-01-01 19:57:59.642 scheduler: Scheduled items: Scheduled 1318 items in 59.8 = 0.00 match + 59.81 place
2007-01-01 19:58:31.831 TVRec(1): Changing from None to RecordingOnly
2007-01-01 19:58:31.833 TVRec(1): HW Tuner: 1->1
2007-01-01 19:58:33.213 ret_pid(0) child(6162) status(0x0)
2007-01-01 19:58:34.214 ret_pid(0) child(6162) status(0x0)
2007-01-01 19:58:35.215 ret_pid(0) child(6162) status(0x0)
2007-01-01 19:58:36.216 ret_pid(6162) child(6162) status(0x0)
2007-01-01 19:58:36.216 External Tuning program exited with no error
2007-01-01 19:58:36.414 MPEGRec(/dev/v4l/video0) Warning: Unable to set recording volume
                        eno: Invalid argument (22)
                        If you are using an AverMedia M179 card this is normal.
2007-01-01 19:58:36.419 MPEGRec(/dev/v4l/video0): Can't enable VBI recording (2)
                        eno: Invalid argument (22)

the frontend locks solid (I can't hit okay on the button). Restarting the frontend fails to reconnect to the backend

It continues until I restart the backend.

Is there any better flags to use to try to track this down?

[Rob Smith]

Small Update, Updating to trunk seems to fix the issue for me

[cpinkham]

Closing ticket unless the issue is repeatable with SVN HEAD and better debugging info is provided as described in the HOWTO. This sounds like the upnp bug that was fixed a while back.