[Xmltv-devel] tv_grab_uk_atlas status

[Robert Eden]

John was having problems sending to the lists, so I'll relay..

I don't know whether it should go into the Users or Developers list,

easy enough.. I'll send to both. :)

Atlas API V3 no longer working - Breaks tv_grab_uk_atlas
As of this morning, calls to V3 of the Atlas API no longer work,
returning a 500 error (Even after checking my API key is valid & that
i've accepted the new T&Cs. However V4 does work.
Isn't it about time the Atlas grabber was migrated to V4 (and
soon-ish, given the RT feed is about to be switched off in a few weeks
too)? Currently that'll leave us with just the new SD_JSON grabber
(which from what i've seen isn't as thorough as the rt or Atlas
sources - they can't be using Press Association data, that's for sure...

Robert

[Dreamcat4]

Post by Robert Eden
John was having problems sending to the lists, so I'll relay..
I don't know whether it should go into the Users or Developers list, but
easy enough.. I'll send to both. :)
Atlas API V3 no longer working - Breaks tv_grab_uk_atlas
As of this morning, calls to V3 of the Atlas API no longer work, returning
a 500 error (Even after checking my API key is valid & that i've accepted
the new T&Cs. However V4 does work.
Isn't it about time the Atlas grabber was migrated to V4 (and soon-ish,
given the RT feed is about to be switched off in a few weeks too)?
Currently that'll leave us with just the new SD_JSON grabber (which from
what i've seen isn't as thorough as the rt or Atlas sources - they can't be
using Press Association data, that's for sure...

Yeah - I'll be missing the PA data source too. That was my main reason for
using ATLAS in the first place.

Post by Robert Eden
Robert
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data
untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
xmltv-users mailing list
https://lists.sourceforge.net/lists/listinfo/xmltv-users

[Jan Ceuleers]

Isn't it about time the Atlas grabber was migrated to V4 (and
soon-ish, given the RT feed is about to be switched off in a few weeks
too)? Currently that'll leave us with just the new SD_JSON grabber
(which from what i've seen isn't as thorough as the rt or Atlas
sources - they can't be using Press Association data, that's for sure...

In my opinion it is not possible for MythTV + the Atlas grabber to
comply with the new Ts&Cs, particularly the requirement that data only
be requested when it is about to be displayed to the user, rather than
requesting all data and "caching" it in a database.

I know that MythTV doesn't request all data (via XMLTV and its grabbers)
only for the purpose of caching but also so as to be able to
algorithmically schedule recordings, but according to my reading of the
Ts&Cs this behaviour is still incompatible with the kind of service
Metabroadcast is willing to provide.

I know that I'm viewing this through the eyes of a MythTV user and that
what Metabroadcast sees are API calls issued by tv_grab_uk_atlas (which
is not necessarily invoked by MythTV or by any other ultimate consumer
of guide data directly), but I somehow don't see XMLTV fitting into a
model whereby the "client" interactively requests Atlas data by means of
the tv_grab_uk_atlas grabber.

So I've mentally written off this grabber.