Re: RFC: Renaming grabbers

Gary Buhrmaster <[email protected]> Tue, 27 Feb 2018 14:55:36 +0000
Newsgroups gmane.comp.tv.xmltv.devel
Message-ID <CAMfXtQy6g8D10_8uZb-47euEjPSbGiow=5qc7W5R0744sgVv0w@mail.gmail.com>
On Tue, Feb 27, 2018 at 11:14 AM, Nick Morrott
<[email protected]> wrote:
> "Mommy, why are my listings broken?"
...
> Protocols for renaming a grabber could include:
...
> There are probably others, but is one method any more favourable than
> the others?

Well, since you asked.....

There is an additional complexity (and cause for confusion) in
some scenarios.  Depending on the packaging/installation
solution used, simply removing old grabbers from the release
may not actually delete them on the users host systems (the
install replaces existing files, but does not delete removed ones).

That results in issues that deleting the old grabber without
replacing it with an explicit "We are dead, go elsewhere"
script for at least one cycle problematic as people see an
(old) script, but it does not work (properly or at all?)

I would suggest that that means that options i and iii are
not optimal.

And while I agree that people tend to ignore emails/warnings
until it actually impacts them, I believe we should give them
a chance (and then have the moral(??) high ground of "We
told you so!").

I think the approach should be a slightly modified option ii
where an interim script exists that (tries to) automatically
redirect with the message for release n (the standard dozen
liner perl code can typically do so), but with release n+1
the redirector script should be replaced with one that
terminates (with message), and then with n+2 be deleted
(so that for packaging/installation solutions that delete files,
it is now gone).

Yes, that does make this an often multi-year effort unless
we (and by we I mean you) start to provide releases more
regularly.  If we track these via github issues (via milestones)
perhaps it will not get forgotten.

> I am guessing here, but I would think the majority of users run a
> grabber either through something like cron, or via a calling
> application (e.g. MythTV) so the chances of seeing run-time output are
> probably reduced.

FWIW, as I recall, due to a bug/feature, MythTV (in particular) does
not produce the output from the grabber even when requested to do
so (which few people likely do in any case because the output can
be very verbose due to other messages that are enabled with that
option) so people get no output from the grabber (it has been on my
list to look at for a few years now but it is not clear if/when I am going
to ever get to it).

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot