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