[mythtv-users] MythTV records but doesn't write to disk...

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

    > Date: Mon, 22 Dec 2008 16:58:46 -0500
    > From: Daniel Kristjansson <danielk at cuymedia.net>

    > On Mon, 2008-12-15 at 08:33 -0700, Brian Wood wrote:
    > > On Monday 15 December 2008 08:16:24 Udo van den Heuvel wrote:
    > > If a station is off the air, it might well come back up in the middle of a 
    > > program, and you might want to record what's left of the program.

    > Bingo! This is why we start "recording" DVB even when there is no signal
    > and hence no data. Some stations have a habit of being off-air until
    > the first prime-time programming of the evening. So say MythTV has a
    > 5 minute pre-roll and the clock at the station is running 1 minute late,
    > then we will not see data until the 6th minute after we start recording.
    > There is a feature request ticket open for detecting when a whole
    > program has gone by without any data being collected, #3872. Stuart M
    > added it to his queue for 0.22 several months ago. I don't know if he
    > will actually get to it before 0.22, but he considers it a "critical
    > enhancement" so my only guess is he will try really hard to implement
    > it in time for the next release.

[Should I move this one message to -dev? (Or CC Stuart directly?
I dunno if he's on -users.)]

Stuart, I would be overjoyed if your patch also allowed two
(apparently) trivial things, whenever it is you get to it:

(a) The ability to call out to a script that gets to decide whether or
    not the recording is defective.  (Many problems are not zero-byte
    but, say, station screws up and has the same single frame frozen
    on-screen for hours---this has happened repeatedly on one of my
    PBS affiliates and it's only one of many dumb failure modes.)
    Presumably it can indicate via its return value what to do, such
    as bit 0 = defective? and bit 1 = delete?, so 0 = everything-ok
    and 3 = rerecord and don't even bother keeping the original.
(b) The ability to keep the existing ("bad") recording, even if we
    rerecord it, for forensics & debugging, and to allow recovery if
    the recording was actually "good".

The idea here is that I have several approaches that aren't too hard
to write to detect a bad recording, but hooking back into the scheduler 
to actually get the thing -recorded- again doesn't look all that
straightforward, and something that scans for bad recordings but then
has to wait for -me- to manually reschedule is too slow---often the
only available repeat is only 2-4 hours later, and it's unreasonable
to expect near-real-time babysitting of a DVR.

Neither of these would need a UI, in my opinion (e.g., just a database
field for "external bad-program detection script" or something similar),
although of course if someone wanted to write a UI and add it to
mythtv-setup that would be great too (I'm just trying to minimize
the amount of work required to implement this).

An alternative to both (a) and (b) would be to take the logic that
says "this recording was bad---reschedule if possible" [minus the
"and delete the old one"] and make it available somehow as a hook
that could be invoked by a userjob.  That way, the same functionality
could be implemented via a userjob that scans the recording as soon
as it's done.

(This is similar to requests I've made about hooking the commflagger
so that its I/O could possibly be shared by other code to avoid
reading a program -twice-, since the commflagger figures out all kinds
of stuff that would be useful to detect bad recordings, but that might
be a more intrusive change; it might take some careful work with
callbacks and the API for it could be messy.)

I've mentioned things like this this in the past before this ticket
existed & could point to more details or rationale if anyone cares.

Thanks!