[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
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.
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
thought.
--
Ticket URL: <http://svn.mythtv.org/trac/ticket/8582>
MythTV <http://www.mythtv.org/>
MythTV
More information about the mythtv-commits
mailing list