[Xmltv-devel] Schedules Direct JSON API grabber

[Kevin Groeneveld]

Does anyone know if someone is actively working on an XMLTV grabber for the
new Schedules Direct JSON api?

I have been trying to learn more about Perl lately and I decided to start
hacking together an XMLTV grabber for the new Schedules Direct JSON API. I
didn't really expect it to go anywhere but it is starting to come together
quicker than expected. If no one else is already working on something
similar that may give me more motivation to keep working on it.

What I have now is almost usable, at least for my setup. I currently have
a few things hard coded and no way to properly configure the lineups. But
I have a schedule with much of the meta data coming up in MythTV now.


Kevin

[Robert Eden]

Cool. Are you storing the days locally so you can do efficient updates?

Post by Kevin Groeneveld
Does anyone know if someone is actively working on an XMLTV grabber for
the new Schedules Direct JSON api?
I have been trying to learn more about Perl lately and I decided to start
hacking together an XMLTV grabber for the new Schedules Direct JSON API. I
didn't really expect it to go anywhere but it is starting to come together
quicker than expected. If no one else is already working on something
similar that may give me more motivation to keep working on it.
What I have now is almost usable, at least for my setup. I currently have
a few things hard coded and no way to properly configure the lineups. But
I have a schedule with much of the meta data coming up in MythTV now.
Kevin
------------------------------------------------------------------------------
_______________________________________________
xmltv-devel mailing list
https://lists.sourceforge.net/lists/listinfo/xmltv-devel

[Kevin Groeneveld]

Post by Robert Eden
Cool. Are you storing the days locally so you can do efficient updates?

I am trying to cache as much as possible locally. I am currently caching
all the program details and channel schedules and only re-downloading them
when the md5 or last modified date changes. This does still result in some
duplicate data being downloaded though as I don't think there is a way to
check specifically which days have changed or to download only a specific
day. I think you can only specify the number of days to download, but it
always starts at the current day. Even so, caching all the program details
and only re-downloading the whole schedule when it changes is already a big
help.

Kevin

[Kevin Groeneveld]

I decided to upload what I have done so far on github:
https://github.com/kgroeneveld/tv_grab_na_sd_json

There is some very minimal documentation in the tv_grab_na_sd_json file.
Comments and feedback welcome.


Kevin

[Robert Eden]

I decided to upload what I have done so far on github: https://github.com/kgroeneveld/tv_grab_na_sd_json
There is some very minimal documentation in the tv_grab_na_sd_json file. Comments and feedback welcome.

Things are stabilizing on the SD-DD service so decided to give this a shot. Unfortunately, I get a raw JSON error about no lineups being defined.

tv_grab_sd_json --configure

Robert

[Kevin Groeneveld]

Post by Robert Eden
Things are stabilizing on the SD-DD service so decided to give this a
shot. Unfortunately, I get a raw JSON error about no lineups being
defined.

It seems I broke the case of no lineups setup for the account at some
point. I just tried deleting all the lineups from my account and then the
configure fails. I just pushed a temporary fix for this problem. It will
still show the messy error message but won't exit the script anymore.
Properly error handling throughout the grabber should probably be my next
priority.

Kevin

[Robert Eden]

Post by Robert Eden
Things are stabilizing on the SD-DD service so decided to give
this a shot. Unfortunately, I get a raw JSON error about no
lineups being defined.
It seems I broke the case of no lineups setup for the account at some
point. I just tried deleting all the lineups from my account and then
the configure fails. I just pushed a temporary fix for this problem.
It will still show the messy error message but won't exit the script
anymore. Properly error handling throughout the grabber should
probably be my next priority.

Sorry for the delay, but I just got around to trying this again (been
buried by replacement SD datadirect server)... Excellent progress, and
usable even at this point.

Some suggestions.

1. add a --debug switch and only output debugging if you specify it.

2. during config, ask the user for a suggested timezone and convert
times to that (with an offset of course). Folks looking at the raw XML
for troubleshooting aren't going to want to see UTC, heck, some apps
ignore timezone and need the XMLTV file in a local timezone.

3. Include more station details (like network, etc). I suspect this is
already on your TODO list.

4. Change channel-ids to a domain style format... maybe
###.json.schedulesdirect.org

Probably after #1, we can even add it to the distribution.. it appears
usable now, and with all the international coverage may really help some
folk.

http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2616&p=8053&hilit=international#p8053

Robert

[Kevin Groeneveld]

Post by Robert Eden
Sorry for the delay, but I just got around to trying this again (been
buried by replacement SD datadirect server)... Excellent progress, and
usable even at this point.

That's okay. My delay was even longer...

Post by Robert Eden
Some suggestions.
1. add a --debug switch and only output debugging if you specify it.

Done. There are only a few status messages now by default. These can also
be disabled with --quiet. Error messages are always enabled.

Post by Robert Eden
2. during config, ask the user for a suggested timezone and convert times
to that (with an offset of course). Folks looking at the raw XML for
troubleshooting aren't going to want to see UTC, heck, some apps ignore
timezone and need the XMLTV file in a local timezone.

I guess that may be a nice to have. I just assumed most apps would handle
UTC. It does seem to be the most logical format to use in a storage format
and then only use local time for display.

Post by Robert Eden
3. Include more station details (like network, etc). I suspect this is
already on your TODO list.

There may be some missing metadata, but I think I got most of it. It is a
little confusing in some cases figuring out the appropriate mapping from
the SD fields to the XMLTV fields.

Post by Robert Eden
4. Change channel-ids to a domain style format... maybe ###.
json.schedulesdirect.org

Done.

Post by Robert Eden
Probably after #1, we can even add it to the distribution.. it appears
usable now, and with all the international coverage may really help some
folk.
http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2616&p=8053&hilit=international#p8053

Interesting. I didn't realize schedules direct had lineups for outside of
Canada and the USA. During the config stage when searching for lineups I
only prompt for USA or CAN, I guess this may need to be extended.

I have also fixed a couple other minor issues in the last couple days. I
really should put a little more effort into better error handling soon.


Kevin

[Robert Eden]

Post by Robert Eden
4. Change channel-ids to a domain style format... maybe
###.json.schedulesdirect.org <http://json.schedulesdirect.org>
Done.

Reading your reply gave me a great idea! I bet SD-JSON uses the same
channel-ids as SD-DD use <channel-id>.labs.zap2it.com

You may think this is crazy, but that will make it very easy for
US/Canada folks using tv_grab_na_dd to transition to your grabber.

Post by Robert Eden
Interesting. I didn't realize schedules direct had lineups for outside
of Canada and the USA. During the config stage when searching for
lineups I only prompt for USA or CAN, I guess this may need to be
extended.

http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2655&p=8346

You may want to ask RobertK if the API provides a list of countries.

There is a very good chance many international folks will use the new
grabber.. especially those that have to use a scraper now. It's why I
recommended not putting "NA" in the grabber name! :)

BTW, you can also use tv_grab_na_dd for mapping ideas, if everything
isn't mapped. I know SD_JSON has extra fields... if there isn't a good
place for it now, we can extend XMLTV to support it.

Robert

[Karl Dietz]

Post by Robert Eden

Post by Kevin Groeneveld
Interesting. I didn't realize schedules direct had lineups for outside
of Canada and the USA. During the config stage when searching for
lineups I only prompt for USA or CAN, I guess this may need to be
extended.

http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2655&p=8346
You may want to ask RobertK if the API provides a list of countries.
There is a very good chance many international folks will use the new
grabber.. especially those that have to use a scraper now. It's why I
recommended not putting "NA" in the grabber name! :)

That may also be a good time to start adding other-language-then-english
strings to the grabber.
Here is an example for a bilingual configuration:
http://xmltv.cvs.sf.net/viewvc/xmltv/xmltv/grab/fr_kazer/tv_grab_fr_kazer?revision=1.6&view=markup#l274

Maybe start with french and spanish as these appear to be in use with
the original target audience, too.

Regards,
Karl

PS: Reminds me to test whether the strings actually get used in the
internal configuration...

[h***@gmail.com]

Post by Robert Eden

Post by Kevin Groeneveld
Interesting. I didn't realize schedules direct had lineups for outside
of Canada and the USA.

http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2655&p=8346
There is a very good chance many international folks will use the new
grabber.. especially those that have to use a scraper now.

That's interesting. Are there any 'sample' files for Europe so I can get some idea of the extent of coverage?

Geoff

p.s. at some stage don't forget to change the 'Sign Up' for SD which currently doesn't include Europe ;-)

[Robert Eden]

Post by h***@gmail.com

Post by Robert Eden

Post by Kevin Groeneveld
Interesting. I didn't realize schedules direct had lineups for outside
of Canada and the USA.

http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2655&p=8346
There is a very good chance many international folks will use the new
grabber.. especially those that have to use a scraper now.

That's interesting. Are there any 'sample' files for Europe so I can get some idea of the extent of coverage?
Geoff
p.s. at some stage don't forget to change the 'Sign Up' for SD which currently doesn't include Europe ;-)

Yea, we need to change our signup page... Maybe even just remove the
address, except for WA state where we need it for sales tax info. :(
Our lawyers said we needed it, but we haven't looked at it in 7+ years
(except for WA state sales taxes).

You should be able to sign up for an account and use the SD_JSON grabber
from Kevin's Git repository and see how good the data is. I suspect the
data is pretty good though.

Let's not scare Kevin *too* much with things like adding language
support to the grabber. :) Get it working and in first!

Robert

[Kevin Groeneveld]

Post by Robert Eden
You should be able to sign up for an account and use the SD_JSON grabber
from Kevin's Git repository and see how good the data is. I suspect the
data is pretty good though.

I just pushed up a change that actually lets you enter a country code other
than USA or CAN. I did successfully grab a listing for Sweeden. I also
tried Denmark and Brazil with some random postal codes. I got a listing of
lineups but it seemed to stall when I actually tried to add one. I am not
sure if that is a problem in my code or something else.

I also renamed the grabber to tv_grab_sd_json. The github repo is now at
https://github.com/kgroeneveld/tv_grab_sd_json, although I think the old
URL also works.

Kevin

[h***@gmail.com]

Post by Kevin Groeneveld

Post by Robert Eden
You should be able to sign up for an account and use the SD_JSON grabber
from Kevin's Git repository and see how good the data is. I suspect the
data is pretty good though.

I just pushed up a change that actually lets you enter a country code other
than USA or CAN. I did successfully grab a listing for Sweeden. I also
tried Denmark and Brazil with some random postal codes. I got a listing of
lineups but it seemed to stall when I actually tried to add one. I am not
sure if that is a problem in my code or something else.
I also renamed the grabber to tv_grab_sd_json. The github repo is now at
https://github.com/kgroeneveld/tv_grab_sd_json, although I think the old
URL also works.

Finally had a chance to have a quick play with this. After modding the grabber for my old version of Perl (no Logical Defined-Or) and older modules (no LWP->put() or HTTP::Message::decodable() or LWP->show_progress()) I downloaded the listings for Sky UK (using country code GBR).

The data seem fairly comprehensive (not had time to x-ref in detail). Just one thing I've noticed is the radio channels on Sky UK actually all begin with leading zero. So for example _sd_json returns

BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101

i.e. both are noted as being on channel "101", but in fact Radio 1 is actually on "0101". Yes really! Don't blame me, blame Sky Broadcasting ;-)

Likewise Radio 2 is actually on "0102" not "102"
BBC Radio 2 BBCR2 102
BBC2 British Brdcstg Corp. BBC2 102
Etc.

I don't know if the zero is being chopped at SD or in the JSON download (TMS used to supply data with the leading zero so I expect the initial feed to SD is ok?).

Cheers,
Geoff

p.s. you might need to migrate to API 20141201 as 20140530 is due to stop serving data in a couple of weeks?

[Kevin Groeneveld]

Post by h***@gmail.com
Finally had a chance to have a quick play with this. After modding the
grabber for my old version of Perl (no Logical Defined-Or) and older
modules (no LWP->put() or HTTP::Message::decodable() or
LWP->show_progress()) I downloaded the listings for Sky UK (using country
code GBR).
The data seem fairly comprehensive (not had time to x-ref in detail). Just
one thing I've noticed is the radio channels on Sky UK actually all begin
with leading zero.

I don't know if the zero is being chopped at SD or in the JSON download

Post by h***@gmail.com
(TMS used to supply data with the leading zero so I expect the initial feed
to SD is ok?).

Thanks for the feedback. I haven't had a chance to test the examples you
gave yet but hopefully I will get to it soon. I have focused my recent
efforts on the API changes.

p.s. you might need to migrate to API 20141201 as 20140530 is due to stop

Post by h***@gmail.com
serving data in a couple of weeks?

I just pushed an update to use the 20141201 API. It has had minimal testing
but at least works for the OTA lineup I normally use. I hope to do more
testing soon. I wouldn't be surprised if it breaks on some lineups or has
other issues.

Kevin

[Robert Eden]

Not much has been mentioned about this for a while.. any updated status
Kevin? Need me to see what else is needed to add this to the distribution?

SD now supports many different countries around the world!
(http://www.schedulesdirect.org/regions)

This grabber may get very popular, very soon.

Robert

[Kevin Groeneveld]

Post by Robert Eden
Not much has been mentioned about this for a while.. any updated status
Kevin?

Since January I have been using the grabber on my live MythTV setup with no
issues. In general I think it is fairly complete and works well under
normal circumstances. It is nice getting a few more days of data and
everything is always more up to date without having to re-download
everything.

It could be more robust when unexpected things happens. I can be a bit of
a perfectionist so I may never think it is ready.

It also seem to be a bit of a memory hog. All of the data is stored in RAM
at once which can be fairly large if you have a lot of channels
configured. And I am using the perl Storable module to cache the data to
disk which seems to almost double the RAM usage as I think it is trying to
de-duplicate strings and other objects during the store operation. This is
all probably okay with the amount of RAM most things have today.

There was talk of xmltv switching from CVS to git. Did this ever happen?


Kevin

[Robert Eden]

Post by Robert Eden
Not much has been mentioned about this for a while.. any updated status
Kevin?
Since January I have been using the grabber on my live MythTV setup
with no issues. In general I think it is fairly complete and works
well under normal circumstances. It is nice getting a few more days
of data and everything is always more up to date without having to
re-download everything.
It could be more robust when unexpected things happens. I can be a
bit of a perfectionist so I may never think it is ready.
It also seem to be a bit of a memory hog. All of the data is stored in
RAM at once which can be fairly large if you have a lot of channels
configured. And I am using the perl Storable module to cache the data
to disk which seems to almost double the RAM usage as I think it is
trying to de-duplicate strings and other objects during the store
operation. This is all probably okay with the amount of RAM most
things have today.
There was talk of xmltv switching from CVS to git. Did this ever happen?

Nope, not yet.. you still have the master copy in Github.

When I last tried it, it was US/Canada only... SD now supports other
countries... can you update it to support that?

I'll take another look at the code for other changes.

Robert

[Kevin Groeneveld]

Post by Robert Eden
Nope, not yet.. you still have the master copy in Github.

My repo on github is just for the tv_grab_sd_json file, it is not all of
xmltv.

Post by Robert Eden
When I last tried it, it was US/Canada only... SD now supports other
countries... can you update it to support that?

I added support for other countries a little over a year ago. I just
removed the choice between "USA" and "CAN" and now allow the user to enter
anything they want for the country code and leave the validation up to the
server. I think there is an API now to get a valid list of countries but I
have not tried that yet. I have tested with several non USA/CAN lineups.

Kevin

[Robert Eden]

I just added tv_grab_sd_json to CVS and the alpha-exe!

It seems to work fine on US and UK listings. Many other countries are
supported ( http://www.schedulesdirect.org/regions )

I removed the "File::HomeDir::my_home" requirement and configured it to
use XMLTV::Config_file module to generate the tv_grab_sd_json.cache
file. Question for the group.. is this how other working file
locations are assigned? Seemed reasonable to me. (That file is a data
cache, the grabber only downloads items that have changed)

I'm not sure I like the ** GET/POST messages. part of me thinks it
should be in a debug mode only. I understand it's not there in quiet
mode and simply uses the progress from UserAgent... we'll see what
others think.. I just may not be used to it. It certainly would be
helpful in troubleshooting.

I wonder if there should be additional line breaks before input
prompts. Again, this could me just not used to it and curious what
others think.

Of course, those things are all cosmetic, great job Kevin!

If anyone needs a SD account to test with, there's a free 7 day trial
at SD ( no billing info asked for)

Robert

[Kevin Groeneveld]

Post by Robert Eden
I removed the "File::HomeDir::my_home" requirement and configured it to
use XMLTV::Config_file module to generate the tv_grab_sd_json.cache
file. Question for the group.. is this how other working file
locations are assigned? Seemed reasonable to me. (That file is a data
cache, the grabber only downloads items that have changed)

I agree that it would be nice to remove the File::HomeDir dependency.
Although I don't think the XMLTV::Config_file::filename function was
originally intended to be used this way. The second parameter is named
"progname" to which is being passed "tv_grab_sd_json.cache". The resulting
filename is then "tv_grab_sd_json.cache.conf". The filename ending in
.conf implies to me it is a configuration file not a cache file.

Looking quickly at the other grabbers I did not see any that use a single
cache file but there are several that use a cache directory. Several of
the grabbers include there own
get_default_cachedir sub which checks various Windows and unix env
variables to determine a home dir. At least two of the grabbers I looked
at repeat very similar code in these functions. It would be nice if this
was brought out into a common shared location in a way that can handle
cache directories and cache files (and other potential data files) in a
consistent manner.


Kevin

[Robert Eden]

Post by Robert Eden
I removed the "File::HomeDir::my_home" requirement and configured it to
use XMLTV::Config_file module to generate the tv_grab_sd_json.cache
file. Question for the group.. is this how other working file
locations are assigned? Seemed reasonable to me. (That file is a data
cache, the grabber only downloads items that have changed)
I agree that it would be nice to remove the File::HomeDir dependency.
Although I don't think the XMLTV::Config_file::filename function was
originally intended to be used this way. The second parameter is named
"progname" to which is being passed "tv_grab_sd_json.cache". The
resulting filename is then "tv_grab_sd_json.cache.conf". The filename
ending in .conf implies to me it is a configuration file not a cache file.
Looking quickly at the other grabbers I did not see any that use a
single cache file but there are several that use a cache directory.
Several of the grabbers include there own
get_default_cachedir sub which checks various Windows and unix env
variables to determine a home dir. At least two of the grabbers I
looked at repeat very similar code in these functions. It would be
nice if this was brought out into a common shared location in a way
that can handle cache directories and cache files (and other potential
data files) in a consistent manner.

Ah, didn't realize I was creating a .cache.conf file. It was a quick
hack, I should have actually looked at the output file.

I looked at the get_default_cachedir stuff and it really just hard-codes
home. I went ahead and cheated again... I generate the
XMLTV::Config_file::filename, but now remove the .conf at the end.

Robert

[Robert Eden]

Kevin,

I'm correcting issues in the XMLTV (cvs) version of tv_grab_sd_json.

If you keep your git repository up, you may want to make a comment to
that effect. On the git page. I think some folks are using the older code.

Robert

[Kevin Groeneveld]

Post by Robert Eden
Ah, didn't realize I was creating a .cache.conf file. It was a quick
hack, I should have actually looked at the output file.
I looked at the get_default_cachedir stuff and it really just hard-codes
home. I went ahead and cheated again... I generate the
XMLTV::Config_file::filename, but now remove the .conf at the end.

I implemented a get_default_cache_file sub similar to the
get_default_cachedir functions to remove the File::HomeDir dependency. It
seems a little cleaner than the XMLTV::Config_file::filename hack.
Although I still think it would be better yet to have the
get_default_cache(dir|file) stuff handled in a common function in XMLTV
somewhere.

I had practically no internet access since Wednesday last week. There has
been a lot of activity on the XMLTV lists since then...


Kevin

[Robert Eden]

You can't see lineups or shows without signing up for an account, but
all that really needs is a username/password/email. A free 7 day trial
is automatically started. No payment information is asked for in
advance. The best place for questions is the SD Forum, but I can try
and answer. I don't really use the SD-JSON service myself. (I'm a SD-DD
guy!)

I've read the data doesn't come from the Press Association, Gracenote
collects it from the networks/stations themselves.

When I request lineups for postal code "W11 2AQ" I see

1. United Kingdom | Satellite | BSkyB - England | GBR-0001172-DEFAULT
2. United Kingdom | Satellite | BSkyB - Scotland | GBR-0001189-DEFAULT
3. United Kingdom | Satellite | BSkyB - Wales | GBR-0001190-DEFAULT
4. United Kingdom | Satellite | BSkyB - Northern Ireland |
GBR-0001191-DEFAULT
5. United Kingdom | Satellite | BSkyB - Channel Isles | GBR-0001192-DEFAULT
6. United Kingdom | Satellite | BSkyB - Eire (Ireland) | GBR-0001193-DEFAULT
7. United Kingdom | Satellite | BSkyB - United Kingdom | GBR-0001505-DEFAULT
8. United Kingdom | Satellite | Freesat - Channel Isles |
GBR-0003011-DEFAULT
9. United Kingdom | Satellite | Freesat - England | GBR-0003012-DEFAULT
10. United Kingdom | Satellite | Freesat - Northern Ireland |
GBR-0003013-DEFAULT
11. United Kingdom | Satellite | Freesat - Scotland | GBR-0003014-DEFAULT
12. United Kingdom | Satellite | Freesat - Wales | GBR-0003015-DEFAULT

Here's a sample record
<programme start="20160524210000 +0000" stop="20160524220000 +0000"
channel="I20630.json.schedulesdirect.org">
<title>Britain's Got More Talent</title>
<desc>Stephen Mulhern presents an access-all-areas pass at
"Britain's Got Talent'.</desc>
<credits>
<presenter>Stephen Mulhern</presenter>
</credits>
<category>Reality</category>
<category>Music</category>
<category>Series</category>
<category>series</category>
<episode-num system="xmltv_ns">9.9.</episode-num>
<episode-num system="dd_progid">EP013129460109</episode-num>
<audio>
<stereo>stereo</stereo>
</audio>
<previously-shown start="20160524000000 -0500" />
<new />
<subtitles type="teletext" />
</programme>

[Marc Thompson]

Hi Robert:

The xmltv grabber for NA only provides absolute episode number. For my setup, which I think isn't uncommon, I've found that even when embedding the episode summary in the dvr filename, plex lookups to thetvdb mostly fail.

It seems that the season/episode is needed. I think json provides that.

Do you have any thoughts on this? I don't think Plex is in the position to own this. I don't see json sources in tvheadend, though there is some ability to connect a helper script.

Thanks

---
Marc Thompson

Post by Robert Eden
You can't see lineups or shows without signing up for an account, but
all that really needs is a username/password/email. A free 7 day trial
is automatically started. No payment information is asked for in
advance. The best place for questions is the SD Forum, but I can try
and answer. I don't really use the SD-JSON service myself. (I'm a SD-DD
guy!)
I've read the data doesn't come from the Press Association, Gracenote
collects it from the networks/stations themselves.
When I request lineups for postal code "W11 2AQ" I see
1. United Kingdom | Satellite | BSkyB - England | GBR-0001172-DEFAULT
2. United Kingdom | Satellite | BSkyB - Scotland | GBR-0001189-DEFAULT
3. United Kingdom | Satellite | BSkyB - Wales | GBR-0001190-DEFAULT
4. United Kingdom | Satellite | BSkyB - Northern Ireland |
GBR-0001191-DEFAULT
5. United Kingdom | Satellite | BSkyB - Channel Isles | GBR-0001192-DEFAULT
6. United Kingdom | Satellite | BSkyB - Eire (Ireland) | GBR-0001193-DEFAULT
7. United Kingdom | Satellite | BSkyB - United Kingdom | GBR-0001505-DEFAULT
8. United Kingdom | Satellite | Freesat - Channel Isles |
GBR-0003011-DEFAULT
9. United Kingdom | Satellite | Freesat - England | GBR-0003012-DEFAULT
10. United Kingdom | Satellite | Freesat - Northern Ireland |
GBR-0003013-DEFAULT
11. United Kingdom | Satellite | Freesat - Scotland | GBR-0003014-DEFAULT
12. United Kingdom | Satellite | Freesat - Wales | GBR-0003015-DEFAULT
Here's a sample record
<programme start="20160524210000 +0000" stop="20160524220000 +0000"
channel="I20630.json.schedulesdirect.org">
<title>Britain's Got More Talent</title>
<desc>Stephen Mulhern presents an access-all-areas pass at
"Britain's Got Talent'.</desc>
<credits>
<presenter>Stephen Mulhern</presenter>
</credits>
<category>Reality</category>
<category>Music</category>
<category>Series</category>
<category>series</category>
<episode-num system="xmltv_ns">9.9.</episode-num>
<episode-num system="dd_progid">EP013129460109</episode-num>
<audio>
<stereo>stereo</stereo>
</audio>
<previously-shown start="20160524000000 -0500" />
<new />
<subtitles type="teletext" />
</programme>
------------------------------------------------------------------------------
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-devel mailing list
https://lists.sourceforge.net/lists/listinfo/xmltv-devel

[Kevin Groeneveld]

Post by h***@gmail.com
Just one thing I've noticed is the radio channels on Sky UK actually all
begin with leading zero. So for example _sd_json returns
BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101
i.e. both are noted as being on channel "101", but in fact Radio 1 is
actually on "0101". Yes really! Don't blame me, blame Sky Broadcasting ;-)

I duplicated this issue. It appears the JSON data does just contain "101"
instead of "0101". I reported the issue on the Schedules Direct forum:
http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2687

Kevin

[Robert Eden]

Post by h***@gmail.com
Just one thing I've noticed is the radio channels on Sky UK
actually all begin with leading zero. So for example _sd_json returns
BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101
i.e. both are noted as being on channel "101", but in fact Radio 1
is actually on "0101". Yes really! Don't blame me, blame Sky
Broadcasting ;-)
I duplicated this issue. It appears the JSON data does just contain
"101" instead of "0101". I reported the issue on the Schedules Direct
forum: http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2687

How strange... not sure how this should be dealt with. I'm sure the
field is treated as an integer somewhere, so the leading zero is lost.

How do applications deal with it? MythTV, others? Do they always treat
the channel number as a string? I suspect not.

Robert

[Robert Eden]

Post by Robert Eden

Post by h***@gmail.com
Just one thing I've noticed is the radio channels on Sky UK
actually all begin with leading zero. So for example _sd_json returns
BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101
i.e. both are noted as being on channel "101", but in fact Radio
1 is actually on "0101". Yes really! Don't blame me, blame Sky
Broadcasting ;-)
I duplicated this issue. It appears the JSON data does just contain
"101" instead of "0101". I reported the issue on the Schedules
Direct forum: http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2687

How strange... not sure how this should be dealt with. I'm sure the
field is treated as an integer somewhere, so the leading zero is lost.
How do applications deal with it? MythTV, others? Do they always
treat the channel number as a string? I suspect not.

Sky-TV doesn't display leading zeros on their online guide:
http://tv.sky.com/tv-guide

I think this is a Cable Box interface problem... the cable box requires
a 4 digit number. The IR code should deal with it. That's not that
unusual, the driver probably supports it.

Robert

[Nick Morrott]

Post by Kevin Groeneveld

Post by h***@gmail.com
Just one thing I've noticed is the radio channels on Sky UK actually all
begin with leading zero. So for example _sd_json returns
BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101
i.e. both are noted as being on channel "101", but in fact Radio 1 is
actually on "0101". Yes really! Don't blame me, blame Sky Broadcasting ;-)

I duplicated this issue. It appears the JSON data does just contain "101"
http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2687
How strange... not sure how this should be dealt with. I'm sure the field
is treated as an integer somewhere, so the leading zero is lost.
How do applications deal with it? MythTV, others? Do they always treat the
channel number as a string? I suspect not.
http://tv.sky.com/tv-guide
I think this is a Cable Box interface problem... the cable box requires a 4
digit number. The IR code should deal with it. That's not that unusual,
the driver probably supports it.

See http://www.mediauk.com/radio/platforms/sky for radio channels.

The online Sky TV guide only shows TV channels.

Cheers,
Nick

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

[Robert Eden]

Post by Nick Morrott

Post by Kevin Groeneveld

Post by h***@gmail.com
Just one thing I've noticed is the radio channels on Sky UK actually all
begin with leading zero. So for example _sd_json returns
BBC Radio 1 BBCR1 101
BBC1 British Brdcstg Corp. BBC1 101
i.e. both are noted as being on channel "101", but in fact Radio 1 is
actually on "0101". Yes really! Don't blame me, blame Sky Broadcasting ;-)

I duplicated this issue. It appears the JSON data does just contain "101"
http://forums.schedulesdirect.org/viewtopic.php?f=16&t=2687
How strange... not sure how this should be dealt with. I'm sure the field
is treated as an integer somewhere, so the leading zero is lost.
How do applications deal with it? MythTV, others? Do they always treat the
channel number as a string? I suspect not.
http://tv.sky.com/tv-guide
I think this is a Cable Box interface problem... the cable box requires a 4
digit number. The IR code should deal with it. That's not that unusual,
the driver probably supports it.

See http://www.mediauk.com/radio/platforms/sky for radio channels.
The online Sky TV guide only shows TV channels.

Wow.. they use a parallel numbering scheme for "radio" as well as TV?
That won't cause any confusion!

Does the SD-JSON service provide data for Media.Info (formerly Sky Radio)


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

[Robert Eden]

FYI.. the SD_JSON grabber is broken. It doesn't implement the latest API.

[Robert Eden]

Post by Robert Eden
FYI.. the SD_JSON grabber is broken. It doesn't implement the latest API.

No it's not.. I'm an idiot for not checking github for an update. Sorry!

(it would be nice to finish the cleanup so we can get this grabber added
to the distro)

[Kevin Groeneveld]

Post by Robert Eden
Reading your reply gave me a great idea! I bet SD-JSON uses the same
channel-ids as SD-DD use <channel-id>.labs.zap2it.com
You may think this is crazy, but that will make it very easy for US/Canada
folks using tv_grab_na_dd to transition to your grabber.

I assume that should be I<channel-id>.labs.zap2it.com. The code in
tv_grab_na_dd is sprintf("I%d.labs.zap2it.com",$sid).

Does it still seems like a good idea? I can't think of any reason not to
change it other than it seems technically inaccurate. It would be very
easy to change.


Kevin

[Robert Eden]

Post by Robert Eden
Reading your reply gave me a great idea! I bet SD-JSON uses the
same channel-ids as SD-DD use <channel-id>.labs.zap2it.com
<http://labs.zap2it.com>
You may think this is crazy, but that will make it very easy for
US/Canada folks using tv_grab_na_dd to transition to your grabber.
I assume that should be I<channel-id>.labs.zap2it.com
<http://labs.zap2it.com>. The code in tv_grab_na_dd is
sprintf("I%d.labs.zap2it.com <http://d.labs.zap2it.com>",$sid).
Does it still seems like a good idea? I can't think of any reason not
to change it other than it seems technically inaccurate. It would be
very easy to change.

Ah, I didn't remember how I calculated it... I don't know why but I
thought the I was part of the channel ID (forgot it's just numeric).

Yes, make the change. It doesn't really hurt anything and can make
migration from tv_grab_na_dd easier.

Robert

[Kevin Groeneveld]

Post by Robert Eden
Ah, I didn't remember how I calculated it... I don't know why but I
thought the I was part of the channel ID (forgot it's just numeric).
Yes, make the change. It doesn't really hurt anything and can make
migration from tv_grab_na_dd easier.

Done.