[mythtv-commits] Ticket #8582: MythTV backend wedging frequently

MythTV mythtv at cvs.mythtv.org
Fri Jun 18 06:07:36 UTC 2010

#8582: MythTV backend wedging frequently
 Reporter:  dgatwood <dgatwood@…>        |       Owner:  ijr        
     Type:  defect                       |      Status:  new        
 Priority:  minor                        |   Milestone:  unknown    
Component:  MythTV - General             |     Version:  Unspecified
 Severity:  medium                       |     Mlocked:  0          
 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.

 2.  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.

 3.  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
                         eno: Resource temporarily unavailable (11)

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

 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.

 4.  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....

 5.  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

Ticket URL: <http://svn.mythtv.org/trac/ticket/8582>
MythTV <http://www.mythtv.org/>

More information about the mythtv-commits mailing list