[mythtv-users] season and episode population from schedules direct json has been incomplete.

Gary Buhrmaster gary.buhrmaster at gmail.com
Sat Jan 20 19:09:55 UTC 2024

On Wed, Jan 17, 2024 at 9:40 PM Tom Dexter <digitalaudiorock at gmail.com> wrote:

> I suppose I may have to change to that sqlite one. On the whole,
> Schedules Direct seems to do a good job, but on occasion they do some
> really questionable stuff. There was that bizarre thing they did some
> time back where they apparently replaced their backend stuff with some
> new python version, which totally broke a lot of stuff.

If the case you referring to is the one I am thinking of
it was moving to a python based microservices
architecture from a monolithic php implementation.

The goal was to be both API compliant, and
to (substantially) reduce technical debt and
cloud services costs.

There were some early identified issues that were
fixed quickly on the server side (some during
early private testing, although some additional
ones were immediately seen when "the public"
first experienced the new implementation).

Reportedly most specification compliant applications
(and there are a number of applications of the
EPG, most of which are not XMLTV grabbers)
worked.  The non-sqlite version of the XMLTV
grabber was not fully HTTP compliant (although
that was fixed upstream), but there was also some
failure when pulling the data that was not even
understood before SD reverted (this was
compounded by an issue that the author of
the non-sqlite grabber was hard to contact,
and the test instance was shutdown as part of the
reversion so as far as I know there was never a
clear understanding of what was going on (either
in the grabber or the server side)).

> They ended up
> having to roll that back, and I've never heard anything about it
> since. It all makes me wonder what they might have done here.

As I understand it, after some initial teething
issues were addressed, the lambda implementation
both ran into the classic thundering herd issue,
and with a database performance issue that made
the thundering herd issue worse.  Rather than
continue to work the issue (there were probably
various solutions, but they would have likely
come at some additional cost and complexity) a
decision was made to revert.  Which, in a way,
is too bad, as it was expected to save SD money
in AWS charges (and if you know AWS, one
thing they are very good at is taking your money).

It is also my understanding that API-NEXT for
the Schedules Direct sources (which at this
point has just a vague "sometime in the future"
target date) will be using the new architecture
(although as the old applications will be using
the older API for quite some time the migration
will be over a longer time period and SD will
be able to see how the herds need to be

More information about the mythtv-users mailing list