[mythtv] [mythtv-commits] mythtv/master commit: 72d437001 by Daniel Thor Kristjansson (daniel-kristjansson)

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

    > Date: Tue, 13 Dec 2011 14:26:29 -0500
    > From: Raymond Wagner <raymond at wagnerrp.com>

    > On 12/12/2011 22:54, Daniel Kristjansson wrote:
    > > On Mon, 2011-12-12 at 21:57 -0500,f-myth-users at media.mit.edu  wrote:
    > >>> >  >  Date: Mon, 12 Dec 2011 23:01:46 +0000 (UTC)
    > >> >       >  From: MythTV<noreply at mythtv.org>
    > >> >       >  Adds 'damaged' video property for poor recordings.
    > >> >  I'm not running master, so I can't submit code for this yet, but may
    > >> >  I suggest that another quality metric is whether or not the recording
    > >> >  contains EAS bursts?  This is a -constant- problem on my Comcast feed,
    > > I hate to contradict what was said in the ticket but since this
    > > requires decoding the audio it's probably best done in an external
    > > program managed by mythtv like how real-time mythcommflag works.
    > > That way libav crashes don't take down the backend. Other than that
    > > I think this is a great idea.

    > The use of 'internal' in that case didn't mean internal to the 
    > mythbackend process, but internal to MythTV in general.  As it stands, 
    > it is not a patch that can be applied to MythTV.  As an external script, 
    > we've been trying to clean out contrib anyway, and aren't adding new 
    > stuff to it.  That leaves it as a proof of concept, sitting there as a 
    > feature request for someone else to implement, whether in mythbackend, 
    > mythcommflag, or some new myth- application.  The author seemed content 
    > leaving it as the external script, and as a matter of principle, we 
    > don't allow feature requests on trac.

Yes.  I've been meaning to move this to the wiki for a while.
I'm not proposing that this (or even a rewritten version of this)
necessarily be included in the myth distribution, although I wouldn't
mind if it was, since we're including other failure analysis as part
of myth and this certainly seems aligned with that.

Also, as Daniel said, having some built-in support in myth for "why
this recording is considered suspect/failed" would be handy.  And my
main point here is that anyone who wants to update it a bit to make it
just tell myth that a recording has failed and should be retried
should feel free to take a crack at it.

[My one proviso:  It would be handy if it could say, though the
bindings somehow, "suspect but -continue to record-, even if you think
it'll be re-aired", because some of the "failures" are in fact okay
(like an EAS burst that lands in a commercial :)  and it's safer to
keep going than to abort, since who knows if the -next- airing will
have a different, and more real, problem, or if the schedule changes
and it never airs again at all.  So my suggest is to mark the recording
suspect/failed but never abort it---just ask for another one as well,
if possible.]