[mythtv] [mythtv-commits] Ticket #6899: Detect programs damaged by their broadcasters and notify the user for rescheduling

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

    > Date: Wed, 27 Jan 2010 10:47:08 +0100
    > From: Petr Stehlik <pstehlik at sophics.cz>

    > MythTV 26. 01. 2010 v 21:17 +0000:
    > >  The consensus appears to be that we should/will handle this internally
    > >  rather than with a script, you can track #3872 (whose fix will encompass
    > >  all recordings, not just firewire ones).  I know that that particular
    > >  ticket doesn't deal with all the things your script purports to, but all
    > >  of the above *should* be handled internally.

    > Well, I have just checked the suggested #3872 and it seems to be simply
    > dead - considering the priority was changed from major/critical to minor
    > and milestone was set to unknown 10 months ago.

    > As I am also hit by zero byte recording from time to time I would think
    > that closing #6899 would be better after the #3872 would at least offer
    > some patches for testing or at least a hope that it will be worked on
    > sometime eventually.

I've been mulling this over for the last month, and I really have to
agree wth Petr---I don't understand the logic in closing this as
wontfix.  I'm less grumpy than genuinely puzzled about the goal.

I agree with the goal that Myth should handle this sort of stuff
internally.  BUT---
(a) The ticket you refer to was opened -three years ago- and last saw
    any human discussion activity -one year ago-.  That implies "will
    probably never become important enough for any developer to
    actually address".
(b) It doesn't actually solve any of the problems that 6899 solves. (!)
    All 3872 addresses is "zero-byte recordings".  It does -not-
    address the problems I see -several times a week-, like EAS bursts
    from my very, very overzealous we-must-test-several-times-a-week
    (on every channel simultaneously, for two minutes each time)
    Comcast cable system, or tens of minutes of frozen video (as just
    happened yet again to me overnight from one of my PBS affiliates
    and happens on -some- channel at least once a month).
(c) Even if what 6899 solves -is- incorporated directly into Myth, it
    still leaves people with similar-but-not-identical issues in the
    lurch.  For example, I'll bet there are other ways for recordings
    to fail that might be easily discoverable with a script, but that
    this one doesn't do---such people then have to reinvent this whole
    framework.  [For example, does the EU, or Australia, have things
    that broadcasters do, like EAS, that mess with transmissions?  I
    sure don't know, and making it hard for local people to solve
    their local problems just puts it all on the developers, who can't
    even test their fixes if they're not in the right country.]
(d) Even if we accept all of the above, if you look at 6899, there are
    several parameters there that users must typically adjust for
    their own environment---things like dB level limits (which
    -cannot- be intuited by Myth because you don't know how much buzz
    they may have on an analog signal, and which vary based on the
    types of programming they watch, e.g., the limits are very
    different for commercial channels and movie channels), and this
    flies in the face of "Myth must have fewer knobs, not more".  I
    don't see how the functionality of 6899 could be integrated -into-
    Myth under that contraint, but calling out to an external script
    makes this sort of thing easy without complicating the UI for
    users who don't care.  (And ading 6899's functionality directly
    into Myth as C++ ---but doing so with no way to adjust the knobs---
    would make it absolutely useless to me, and I'd just keep running
    my own code anyway.]

It's possible that what you're really saying is "Myth will eventually
have an extensible framework to allow user-written external scripts to
make decisions about whether a recording is good, and to tell Myth to
try again if it's not."  That's a laudible goal, and one I've been
talking about for years.  But that doesn't seem to me to be what's
going on in what you're saying about 3872, nor does it look like even
3872's relatively unambitious goal will happen anytime soon.

[And if it -is- what's going on, then 6899 is exactly such a script.
In fact, with the new event system, one could easily run 6899 from an
event, and with some binding to say, "Go ahead and reschedule", one
could then reschedule, too.  But you're -still- talking about external
scripts unless it is your intention to put silence detection, EAS
detection, and -anything else that any user anywhere might want to
detect- directly into Myth's code.  Should EU/NZ/AU users -really- be
running the US-only EAS detector?]

Instead, you seem to be saying, "We hope eventually that 3872 will
grow to encompass all the ways recordings might be damaged and will
arrange to tell the user and/or reschedule automatically."  That's
nice, but it's been open 3 years with zero progress, so let's just
say that I don't trust this assertion as far as I can throw it.

So what we have here is some tested, working code that could help
people TODAY to know immediately---not days/weeks later when they
finally sit down to watch something that is no longer being repeated
---that a recording they were looking forward to was munched by
something upstream of Myth.  It has absolutely no impact on Myth if
the user doesn't arrange to run it, because it's not compiled into
Myth.  And it's version-independent of Myth---anyone running Myth
from the last 5 years (and probably the next 5 years) could use it.

Myth has, in the past, taken stuff in contrib as a testing ground
for things that might eventually make it into the mainline.  I'd be
perfectly happy if 6899 was in contrib for as many releases as it took
for its functionality to wind up directly in Myth, and then it left
contrib again because it was a part of Myth.

But throwing away a working solution for a vague promise that sometime
in the future someone else will reimplement the same code, maybe, and
that we shouldn't solve the problem right now because some year
someone else might do it instead seems peculiar to me, and feels like
a case of not-invented-here syndrome.  It certainly doesn't motivate
me to send any more enhancements.  I'm sure that's not the goal here,
but it may well be the effect.