[mythtv] Scheduler needs table keys?

[f-myth-users at media.mit.edu]

    > Date: Sun, 4 Mar 2007 00:23:03 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * On Sat Mar 03, 2007 at 11:26:46PM -0500, f-myth-users at media.mit.edu wrote:
    > > The thing that weirds me out a little about this is that those IOBOUND
    > > errors were really common around scheduler runs.  I suppose I could be

    > I can see how that could happen.  The scheduler inadvertently blocked the
    > recorded table.  The recorder got hung up waiting to update
    > recorded.filesize.  The ivtv buffers filled up.  Now, all the sudden the
    > scheduler query finishes, the recorder updates recorded.filesize and
    > starts grabbing all that queued up data which in turn filters it's way
    > over to TFW which potentially kicks out a few IOBOUND errors because
    > of the surge of data it just received.

Hmm.  Yeah, I suppose that could be it.  There was never a 1:1
correspondence between IOBOUND and visible corruption (sometimes
I had corruption w/o it, and sometimes even an IOBOUND didn't lead
to anything incorrect-looking in the stream), but it was strongly
correlated.

    > > Is there any command-line-based tool I can run on an ivtv-generated
    > > mpeg file to detect whether it's been corrupted?  E.g., something that
    > > just looks for keyframes where they're supposed to be, etc?  I'd like

    > You might be able to do this with one of the replex tools, or grep
    > the output of mythtranscode's mpeg2 -> mpeg2 side redirected to /dev/null.

Interesting.  I'll check 'em out.  (Presumably I need mythtranscode
from .19 or later 'cause there wasn't lossless mpeg2 in .18?  If so,
I'll pull the SVN version & compile; how usable is mythtranscode
as a command-line utility without all the rest of myth installed?
I'll actually probably be doing this on some machine that is NOT
one of my myth prod machines, so I won't have to worry about two
sets of incompatible libraries hanging around or whatever, but I'm
hoping mythtranscode doesn't need to talk to a database or whatever.)

I'll also look at replex.

The 0.10.x branch of ivtv has a tool called ps-analyzer, which I've
just tried, but unfortunately it didn't show any problems in a
recording with a visible glitch in it.  I've asked on the ivtv lists
if they have any ideas as well (I'm not sure if ps-analyzer is
designed to detect this kind of problem, e.g., whether this is a
bug or I'm just using it wrong).

Thanks!