[mythtv-users] Status of Schedules Direct SD-JSON grabbers

[Gary Buhrmaster]

On Sun, May 22, 2016 at 9:07 PM, Nick Morrott <knowledgejunkie at gmail.com> wrote:
...
> Note that tv_grab_na_sd requires Perl 5.16 which *may* be an issue for
> some end users - e.g. CentOS 6.6 latest Perl is only 5.10...
>
> From an XMLTV perspective it's always good to try and minimise
> specific minimum Perl versions _where possible_.

I agree.  But I also know that at least one revision of the
grabber (I tried a number of approaches in the (at this
point) nearly two years of on again/off again (mostly
off) work on the development of the grabber) required
(one or more) modules/language features/bug fixes
which required a more recent perl.  I did not keep good
enough notes to document the specific differences
between module, language, and bug fixes required in
those later perl versions.  I have have this vague
recollection I ran into threading, unicode, termination,
and simply perl bug issues, but in any case, I am pretty
sure 5.10 was not good enough.

Now, over the period and revisied approches of the
development of the grabber, it may be that the
modules/language feature/bug fixes that required that
level of perl to properly operate may have been
removed or relaxed.  But such review/testing/validation
has not been performed (especially of the edge/failure
cases, they are always the hard ones to test).  Just a
side note, in recent perls, 'use <version>' also implies
the equivalent of some 'use <features>', so just deleting
the 'use <version>' may break something elsewhere.

I will note RH has a habit of back-porting specific
customer requested fixes to previous versions of software
but leaving the major version unchanged in order to
support their enterprise customers.  Which makes
knowing what actual fixes and features are in there an
exercise in reviewing the detailed build patches (and
not looking at the major version string), which makes
knowing what a RH 5.10 is nearly impossible (it is
not the perl you think it is).

As a bypass, since the grabber itself can run on a system
other than the one running the BE, one could always pick
up a low cost ARM system and run the grabber there
(note that it will take some time to run on some low
power/cost ARM systems, but I have a proof by example
it does run there (slowly)).  And while I understand that is
not a great solution, it may be cheaper, easier, and faster
than doing the actual research to verify that all the
features and bugs are resolved in what are now
end-of-support versions of perl (technically anything
less than 5.22 is now end of support).

Alternatively, RH offers a "upgrade in place" tool kit for
RHEL 6 to RHEL 7 with makes upgrades "easy" (for
some values of "easy" which never seem to apply to
your specific case, but the tools are out there).