[mythtv-users] Schedules Direct TBA Listings

[Gary Buhrmaster]

On Wed, Jul 23, 2014 at 6:12 PM, R. G. Newbury <newbury at mandamus.org> wrote:
....
> If that is the operative philosophy, then mythfilldatabase should not write
> to mythconverg either. It too is a actually a standalone grabber. It just
> happens to be the first one written to talk to Zap2it/Tribune etc. and so it
> was/is included in the myth package.

In the ideal world (I am not doing the coding, so I do not
get to implement the ideal world), mythfilldatabase
(or whatever it is called, perhaps, a rose), would
just load the XMLTV data that was obtained by other
grabbers into the targeted channels.  It would not
have any embedded grabber capability (which it has
for zap2it/SD for good legacy reasons).  This is
an aberration, which, ideally, would be eliminated.

As has been pointed out, there is an existing
xmltv grabber for SD.  That mythfilldatabase has
not been converted to it was due to the (special)
functions that mythfilldatabase performs for SD
that have not (yet) been removed or migrated to
other methods, and lack of resources to do many
things (and one prioritizes).

Now, to take your idea to its logical conclusion,
mythconverg should also store all the xmltv
database information (configuration is a database
with a different format).  That would seem to most
competent DBAs as the wrong way forward.

Now, one cannot always create the ideal today.
But one should also know where one wants to
be (and I think Michael Dean documented that),
and one wants to make sure that you are moving
towards where you want to be, and not just adding
another kludge, and going in the wrong direction.

I happen to applaud Roberts work as a great
POC as to how to move things forward.  That
does not mean I think the POC should be
declared production quality.

We can, of course, agree to disagree.

Gary