[mythtv-commits] Ticket #13084: ttvdb.py will cease to function - TTVDB will discontinue support for V1 XML API in 3 months time on October 1st, 2017

[MythTV]

#13084: ttvdb.py will cease to function - TTVDB will discontinue support for V1 XML
API in 3 months time on October 1st, 2017
-------------------------------------------------+-------------------------
 Reporter:  Frederick Henderson <frederickjh@…>  |          Owner:
                                                 |  markspieth
     Type:  Bug Report - General                 |         Status:
                                                 |  assigned
 Priority:  minor                                |      Milestone:  29.0
Component:  MythTV - Mythmetadatalookup          |        Version:
                                                 |  Unspecified
 Severity:  medium                               |     Resolution:
 Keywords:                                       |  Ticket locked:  0
-------------------------------------------------+-------------------------

Comment (by Gary Buhrmaster <gary.buhrmaster@…>):

 I finally had a little time (while a compile was running) to look over the
 pull request.

 First, let me thank Mark for the raising of the hand to do this work.
 While I personally do not use ttvdb, I know that it is used by many, and
 keeping it working is important to those people.

 Secondly, I am not a dev, and my opinions (AFAIK) carry no weight with
 anyone that actually matters, but I do have opinions, and so I will share
 them, but one should feel free to ignore them in preference to official
 responses.

 Now on to the review.  Note that this is based only looking at the pull
 request and the code.  I have not actually tested it.

 While there is no formal review process in the project, I have a couple of
 concerns about the current pull request.

 First, while I would rarely use quite the flowery language used by Linus
 on the LKML, I do agree with him that mixing new features with bug fixes
 should result in the entire patch being rejected with prejudice.  While
 changing the bindings to support python3 is goodness in the long run, that
 has nothing to do with fixing the ttvdb script which (as has been stated
 elsewhere?) runs with python2.  A python3 port of the bindings should be a
 separable (developer task?) ticket, with a separate pull request, likely
 targeted just to the master branch.  Separating the python3 patches will
 also reduce the required new dependencies to (I think) just
 python2-requests.  Again, simpler is better (especially for something that
 needs back-porting).  Also, depending on distro/packging, python3 modules
 can have packaging requirements (different library locations) that can be
 problematic and has additional dependencies for packagers.  Again, if not
 needed, not appropriate for backporting.  I will also note that one of the
 devs, I think Mr. Wagner (I think it was Mr. Wagner, but it has been long
 enough that my pointer may be pointing to previously freed and now
 overwritten memory) suggested he had issues with using the various python
 compatibility import libraries (six and/or future?), so it may be good to
 ask for an opinion on the use of those compatibility imports (I do not
 remember if the issue(s) were philosophical, or known incompatibility, or
 what (and whether any of those concerns are still operational)) in the
 separate developer task ticket for python3 binding update.

 Secondly, there is a (legacy, but now identified) issue with the use of an
 embedded apikey that cannot be (easily) modified.  There were known to be
 individuals using MythTV as a base for commercial profit (MAAS?).  The
 ttvdb TOS currently explicitly states that an apikey cannot be used
 (without approval, and I presume payment/licence) for anything involving
 commercial use.  Embedding a apikey is a default enabler of misuse, and
 ttvdb would be well within their rights to revoke that key if it is so
 identified.  And while it admittedly is true that that is also with the
 existing ttvdb TOS and the current apikey, it is unclear (to me at least)
 whether the TOS has changed over the years regarding commercial use, but
 it is clear now.  And it has been my interpretation that the project has
 been quite consistent that it will not knowingly assist in the misuse of
 others content (why patches that bypass other sites limitations are not
 accepted), and this means (again, in my interpretation) that the default
 should likely not be to embed an apikey that is restricted and not at all
 easily modified.  Whether the best solution is to require every user to
 have their own separate apikey, or install a key from a well known
 location (after agreeing that it will be used only for personal use), and
 then stored in the file system somewhere (like the raopkey?), or store
 some value in the settings table (value='ttvdb_apikey", data="whatever"?),
 is likely a good discussion (as signing up in order to get a personal
 apikey is free, that has the potential added benefit that it might
 encourage a few someones to be contributors, and not just takers, from the
 metadata source).

 Lastly, I like python requests.  It makes things a lot easier.  While
 there are some features where requests is required (certain socket level
 options), it is often possible to rework the code (with additional pain)
 to use the legacy urllib functionality.  However, as I am not doing to
 work, I am not going to recommend someone else make that effort either
 unless it is obviously trivial.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/13084#comment:30>
MythTV <http://www.mythtv.org>
MythTV Media Center