Opened 11 years ago

Closed 11 years ago

#8582 closed defect (invalid)

MythTV backend wedging frequently

Reported by: dgatwood <dgatwood@…> Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: MythTV - General Version: 0.23rc2
Severity: medium Keywords:
Cc: Ticket locked: no


I'm having some pretty serious problems with the backend on Mythbuntu 10.04, revision 24158 of 0.23-fixes, most of which look like bugs in mythtv itself.

  1. I'm getting several segfaults per day in the backend---reliably at offset 0x153000 in libc and offset 0x276000 in libQt---and also several segfaults per day in mythfilldatabase---reliably at offset 0xb5a95000 in libmyth. I realize that's not very useful without debug symbols or a backtrace. I'll try to build a debug config off the SVN trunk when I have time and update this bug.
  1. About every 12-18 hours worth of recording, something goes massively wrong in the backend and it suddenly starts producing zero-length recordings, Live TV fails to open, etc. It's recording pretty much back-to-back right now, so when it fails, it's really obvious. One recording is perfect, the next is just plain not there.

In the logs, when it wedges, I get this:

2010-06-17 14:30:05.294 DevRdB(/dev/video0) Error: Poll giving up 2010-06-17 14:30:05.330 MPEGRec(/dev/video0) Error: Device error detected 2010-06-17 14:30:05.334 DevRdB(/dev/video0): Stop(): Not running.

There are no errors or warnings in the kernel log for several hours prior, so if this is a driver glitch, it's a very silent one.

Killing and restarting the backend brings things back to normal *immediately* without necessitating any unplug-replug of my USB capture hardware, unloading and reloading drivers, or anything else, so although this is probably triggered by some weird driver bug in pvrusb2, something is also going catastrophically wrong in the backend and the backend is unable to right itself once it does.

  1. Apparently the backend code doesn't cleaning up threads properly on video failure; after a few dozen iterations of the errors in #2, it eventually adds another message to the pile:

2010-06-17 14:41:31.795 DevRdB(/dev/video0) Error: Poll giving up 2010-06-17 14:41:31.808 MPEGRec(/dev/video0) Error: Device error detected 2010-06-17 14:41:31.814 DevRdB(/dev/video0): Stop(): Not running. 2010-06-17 14:41:31.822 DevRdB(/dev/video0) Error: Start(): pthread_create failed.

eno: Resource temporarily unavailable (11)

at which point the backend is beyond hosed because it can't spawn new threads.

These problems are happening often enough and reproducibly enough that I can run any debug builds you'd like me to try and tell you within a couple of days if it fixed the problem.

  1. I'm also frequently getting seriously damaged recordings with jerky video that looks like chunks of the MPEG video data is missing or repeated (breaking up video with visible macroblocks, jumping backwards and forwards, etc.). I'm thinking it's a massively broken ring buffer implementation somewhere that doesn't correctly back the read pointer away from the write pointer on an overrun or underrun.

I can't reproduce this behavior in Live TV mode no matter how many times I try (I've done it dozens of times). All the video profile settings for Live TV are identical to all the other profile settings. No idea if that's useful debugging information, but it struck me as very odd.

I've cranked up the disk cache settings from the default ~9 megs (~13 seconds) up to 64 megs (~94 seconds) and we'll see if that helps. I'm not holding my breath, though....

  1. On several occasions, I've gotten hundreds of these messages in the backend logs:

2010-06-17 09:30:40.988 [mpeg2video @ 0xb668e960]warning: first frame is no keyframe

repeating several times a second, sometimes for minutes at a time. They appear to be harmless---the recording from that time plays correctly---but I'm curious what's causing them.

P.S. Have you and the rest of the Linux community ever considered generating external symbol files for binary releases? Mac OS X does this for kernel extensions, and it makes it rather easy to get backtraces without having to potentially rebuild core system components.... Just a thought.

Change History (1)

comment:1 Changed 11 years ago by stuartm

Resolution: invalid
Status: newclosed
Version: Unspecified0.23rc2

I'm going to start with the obvious first step. [24158] was before the 0.23 release, probably one of the early release candidates, several issues including segfaults were fixed before (and after) the release at [24521]. Mythbuntu make available daily? package updates against the 0.23-fixes branch, they can be enabled through the mythbuntu-control-centre app, see their wiki for more details.

If you can update to the latest packages and then report the issues which aren't fixed, one per ticket, taking care to see that they have not already been reported.

FWIW #5 is just a warning from ffmpeg, it can be ignored. #4 may be configuration related, bring it up on the mythtv-users mailing list. #1-3 are almost certainly fixed in the latest version of fixes.

mythbuntu supply -debug packages including the symbols. Again this should be covered on their wiki.

Note: See TracTickets for help on using tickets.