[Xmltv-devel] Schedules Direct AU and NZ data offering

[Robert Kulagowski]

http://forums.schedulesdirect.org/viewtopic.php?f=15&t=2841

Before I announce to places where users will see it, please test your
JSON grabbers. It should just be another lineup available to add to
your account.

------------------------------------------------------------------------------

[Kevin Groeneveld]

Post by Robert Kulagowski
http://forums.schedulesdirect.org/viewtopic.php?f=15&t=2841
Before I announce to places where users will see it, please test your
JSON grabbers. It should just be another lineup available to add to
your account.

I just did a quick test with my grabber. In general it seems to work fine
but I didn't really check that closely.

One thing I did notice is that some programs don't seem to include an
entityType field which I have never seen before. This triggers a perl
warning in my grabber but doesn't stop it from working. I should maybe
handle this case more explicitly. Some examples:

Lineup AUS-QLD0256-DEFAULT, programID EPAU2342003019
Lineup NZL-NZ0274-DEFAULT, programID EPNZ2908073820


Kevin

[Gary Buhrmaster]

On Sat, Aug 27, 2016 at 10:19 PM, Kevin Groeneveld

Post by Kevin Groeneveld
One thing I did notice is that some programs don't seem to include an
entityType field which I have never seen before. This triggers a perl
warning in my grabber but doesn't stop it from working. I should maybe
handle this case more explicitly.

As the Schedules Direct JSON data definition specifies
"entityType: string. Mandatory" that sounds like another
(source) data issue(*). I (privately) reported another case
of a mandatory field (the md5) not existing in an example
that was identified/fixed almost as soon as I reported it
(maybe before I reported it?), which was apparently due
to some race conditions in data creation.

The joys of data in-gestation from disparate sources.


(*) I would assert that if a mandatory field is missing
that a program is allowed to behave "differently", and
claim "It is not my fault!". Of course, handling bad data
is always a plus, but you can only test and handle so
many cases of challenged source data.

------------------------------------------------------------------------------

[Robert Kulagowski]

On Sat, Aug 27, 2016 at 5:49 PM, Gary Buhrmaster

Post by Gary Buhrmaster
On Sat, Aug 27, 2016 at 10:19 PM, Kevin Groeneveld

Post by Kevin Groeneveld
One thing I did notice is that some programs don't seem to include an
entityType field which I have never seen before. This triggers a perl
warning in my grabber but doesn't stop it from working. I should maybe
handle this case more explicitly.

As the Schedules Direct JSON data definition specifies
"entityType: string. Mandatory" that sounds like another
(source) data issue(*). I (privately) reported another case
of a mandatory field (the md5) not existing in an example
that was identified/fixed almost as soon as I reported it
(maybe before I reported it?), which was apparently due
to some race conditions in data creation.
The joys of data in-gestation from disparate sources.

I've re-generated the programs for AU/NZ and made sure that they have
an entityType now.

------------------------------------------------------------------------------

[Gary Buhrmaster]

Post by Robert Kulagowski
I've re-generated the programs for AU/NZ and made sure that they have
an entityType now.

Thanks (amusingly, for my grabber, I actually had code that
said "entityType is supposed to be mandatory, but ..." and
handled that case, but I had not done so for a missing md5).

I suppose if I got motivated (in my copious free time) I would
create a program to generate "fake" randomly wrong data to
see just what other edge cases my code does not currently
handle (or handle well). A fuzzer by another name?

------------------------------------------------------------------------------