[mythtv] Scheduler needs table keys?

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

    > Date: Sat, 3 Mar 2007 21:46:59 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * On Sat Mar 03, 2007 at 09:31:06PM -0500, f-myth-users at media.mit.edu wrote:
    > > When I did LOCK TABLES RECORDED WRITE; for 30 seconds to demonstrate
    > > that it'd cause the unpatched SBE to hang and trash its recording
    > > (which it certainly did), I also noticed that my "-v all" log for that
    > > recording did -not- have any IOBOUND errors even though it was clear
    > > that I'd dropped 30 seconds of buffers.

    > The IOBOUND error messages come from the ThreadedFileWriter when things
    > are being put in faster then they are being written out.

Err...  right. :)  It only says so in the IOBOUND error. :)
But this brings up a weird question then (see below).

    > If the main recorder loop was blocked trying to write to the recorded
    > table, then it wasn't capturing any data so there wasn't anything to
    > write.  When the ivtv buffer filled up and the mpegrecorder hadn't
    > read any data yet, the ivtv driver started dropping data.

Right.  In fact, my SBE's syslog shows exactly what I'd expect:  a
slew of "ivtv0 warning: ENC Stream 0 OVERFLOW #nn: Stealing a Buffer"
errors a few seconds after I locked the table, so that's the recorder
loop blocked from reading the ivtv buffers from the kernel.  [I also
see this whenever a stream -ends-, which I noticed a few months ago:
looks like Myth stops reading from the stream but doesn't tell ivtv
to stop filling it until later.  I dunno if this is fixed in later
revs than myth 0.18.1/itvtv 0.4.1; guess I'll find out at some point.]

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
seeing two effects:  dropped data from ivtv (reflected in my syslogs)
-and- contention for the disk between MYSQL and ThreadedFileWriter
(and such contention would likely make the DB lock last longer, hence
increasing the chances that ProcessData would drop ivtv data).

I suppose I could try -not- optimizing my DB for a few days and see if
IOBOUNDs surface, even if ivtv errors don't.

So one more question, which I'll put in a separate thread if nobody
has any ideas here:

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
to scan my recordings (especially ones that haven't been watched yet)
and immediately reschedule them for rerecording if the stream's been
corrupted.  (Unfortunately, I don't have syslog archives back more
than a few days---otherwise, I could look -there- by correlating
timestamps on OVERFLOW errors vs Myth's starting/ending-recording
messages, which I -do- archive.  *sigh*)