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

Michael T. Dean mtdean at thirdcontact.com
Mon Mar 1 20:32:49 UTC 2010


On 03/01/2010 03:00 PM, f-myth-users wrote:
> 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.
>    

Don't take this as official MythTV or MythTV developer position, but at 
least from my (personal) perspective, what I would be saying is, "I 
don't care to maintain your hack in official MythTV.  We plan to do it 
right or not at all."

(Note, also, that "hack" is not meant as an insult.  I write a lot of 
hacks--and I have a ton of hacks that I use throughout my network 
because sometimes "doing it right" just isn't worth the effort when 
there's a quick solution for a problem I'm trying to solve.  Also, in 
many cases, my hacks develop over the years into better solutions just 
because I gradually improve them over time.  That said, I would never 
expect any of my hacks to be accepted by someone else into a code base 
they maintain.  Still, I've offered some of my hacks to other people to 
use when the scripts were helpful for them.  That's pretty much exactly 
what happened with your scripts--they're up there for others to use if 
they find them helpful.)

> 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.

And it's still there in the ticket for anyone who feels it's necessary 
for their particular situation.

>    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.
>    

And what we have now is a mish-mosh of unmaintained, legacy, 
use-at-your-own-risk code in contrib that we can't throw away because 
people have come to expect that the (often-dangerous) scripts are an 
official feature of MythTV.  Therefore, developers are now wasting too 
much time on these broken hacks and on the data breakage and other 
problems they cause.  (I'm not commenting on your scripts, but, 
specifically, I'm thinking of the myth_find_orphans.pl and 
myth.rebuilddatabase.pl scripts.  There are many others in contrib that 
are equally bitrotted.)

> 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.
>    

It's not thrown away.  It's still in Trac, and it's available for anyone 
to use in an unmaintained, use-at-your-own-risk fashion--just like what 
we used to do for contrib.  We've just learned since then that putting 
something in contrib gives users an expectation that it will be 
maintained--by us (even the authors tend to disappear and leave all 
maintenance for the already-busy developers).  Reference all the tickets 
on myth_find_orphans.pl and myth.rebuilddatabase.pl.  So, why do the old 
ones get to stay when the new ones aren't accepted?  Well, I, 
personally, am writing the functionality to do what myth_find_orphans.pl 
and myth.rebuilddatabase.pl scripts do, but doing it correctly--in 
mythbackend and mythfrontend--so we can delete those 2 scripts.

And, really, would it be any better if we left #6899 open but unreviewed 
and never included in contrib until MythTV 0.54, when we finally provide 
all of the functionality you want inside MythTV, and then close the 
ticket as "fixed" with a different approach?

We do appreciate your contribution, and there may be other users out 
there who find it useful and use it.  If so, I'd like to thank you for 
the work you put into creating it and, especially, for helping others to 
make their systems better.  However, I think that leaving the scripts in 
a ticket on Trac is better than putting them into contrib and making all 
users see them as an official/approved/promised-to-be-maintained-by-us 
solution for any recording problems.

Mike


More information about the mythtv-dev mailing list