Schedules Direct EPG Plugin PoC Completed

[Slugger]

Originally Posted by Fuzzy

The hope is that if sage does pull the plug on their epg data, then that will be the case. however, until sage stops paying zap2it for the data, tribune (schedules direct) isn't going to give it away for free.

This is correct and this is the reason I can't release the plugin. It's not SD so much that is stopping it, but rather Tribune. I ask SD, they need to get an exemption from Tribune, which Tribune won't give. Without any personal knowledge of the agreement between SD and Tribune, it's my guess that Sage/other commercial entities pay Tribune way more than SD pays for the data and so as long as Sage/Google is paying Tribune, they aren't going to give users access to cheaper listings data in the hopes that Sage/Google will renew their contract. Once Sage/Google is officially no longer an income source of Tribune's then I assume they'll open it up.

Originally Posted by tvmaster2

so then why couldn't someone approach SD with a proposal to pay them, aka a bulk rate for all 'ex' Sage owners, i.e. if you have a sage license you can pay for the data. Say $10 year per license? Why wouldn't they want a piece of that?

Someone could approach SD and/or Tribune if they felt the need. I guarantee that person won't be me. I'll happily write the code and release it open source when I'm able to, but I have zero interest in red tape and other administrative functions - I get enough of that with my real job.

As it stands, the plugin sits in my private svn repository collecting virtual dust. The last time I played with it, it worked at pulling in the data and connecting with users' SD accounts. I didn't bother going any further with it at the time since Tribune said no to me releasing it. When I get a sense that I might be able to release it then I'll merge it into the mc2xml plugin and provide the same kind of data manipulation/filtering functions, etc. that the mc2xml plugin already provides.

[tvmaster2]

Originally Posted by Slugger

This is correct and this is the reason I can't release the plugin. It's not SD so much that is stopping it, but rather Tribune. I ask SD, they need to get an exemption from Tribune, which Tribune won't give. Without any personal knowledge of the agreement between SD and Tribune, it's my guess that Sage/other commercial entities pay Tribune way more than SD pays for the data and so as long as Sage/Google is paying Tribune, they aren't going to give users access to cheaper listings data in the hopes that Sage/Google will renew their contract. Once Sage/Google is officially no longer an income source of Tribune's then I assume they'll open it up.



Someone could approach SD and/or Tribune if they felt the need. I guarantee that person won't be me. I'll happily write the code and release it open source when I'm able to, but I have zero interest in red tape and other administrative functions - I get enough of that with my real job.

As it stands, the plugin sits in my private svn repository collecting virtual dust. The last time I played with it, it worked at pulling in the data and connecting with users' SD accounts. I didn't bother going any further with it at the time since Tribune said no to me releasing it. When I get a sense that I might be able to release it then I'll merge it into the mc2xml plugin and provide the same kind of data manipulation/filtering functions, etc. that the mc2xml plugin already provides.

ok...when the time comes, one of us will be the beaurocrat.

[mkanet]

Sorry if this these are really dumb questions. But I just want to be certain I understand clearly...

Will our sageTV EPG menu (and other menus tied into our EPG) function and look exactly the same as now after we switch to the Schedules Direct plug?

For example, will our "First Run"/"HD" icons, TV show descriptions, specials, guest stars, Sports team information, channel logos, etc will all still be available once we switch from zap2it to the Schedules direct?

Will we have to do anything other than create a Schedules Direct account on their website and install/enable the SD plugin (once the agreement between sageTV/zap2it end).

[Slugger]

Originally Posted by mkanet

Sorry if this these are really dumb questions. But I just want to be certain I understand clearly...

Will our sageTV EPG menu (and other menus tied into our EPG) function and look exactly the same as now after we switch to the Schedules Direct plug?

For example, will our "First Run"/"HD" icons, TV show descriptions, specials, guest stars, Sports team information, channel logos, etc will all still be available once we switch from zap2it to the Schedules direct?

Yes, for the most part. Read this section of the mc2xml plugin docs to get a list of features that are lost/unstable/etc. when using the plugin vs. the Sage EPG service. It basically holds true for the SD plugin.

Will we have to do anything other than create a Schedules Direct account on their website and install/enable the SD plugin (once the agreement between sageTV/zap2it end).

Again, read the installation section of the mc2xml plugin. It won't be nearly as complicated for the SD plugin, but you will have to reconfigure your video sources to hook them up to the new EPG listings. Uninstalling will also require some manual edits to the Sage.properties file (also discussed in the mc2xml plugin docs). These manual steps can't be avoided because of how plugins have to hook into the core to modify the EPG source.

Once you set things up, it's all good and will look and feel just like the current Sage EPG, except for some of the missing features (season/episode numbers, etc.). Updates to the plugin are seamless - just click and install the plugin update. The few minor manual steps are only required at initial install and during an uninstall.

[mkanet]

Thanks so much for the link Slugger.

I didnt see "First Run" as one of the missing features. Maybe it goes without saying that it's not missing? My favorites completely depend on that data being accurate.

Is there any way to supplement the missing features using "groovy scripting" if I get the "licensed version"? I'm guessing that's why this enhancement was added and documented in the first place. Is Groovy scripting some form of web scraping?

"Ability to pull in additional EPG data from other sources to supplement or correct/update the available EPG data through the use of Groovy scripting**"

Thanks for all your effort!

Originally Posted by Slugger

Yes, for the most part. Read this section of the mc2xml plugin docs to get a list of features that are lost/unstable/etc. when using the plugin vs. the Sage EPG service. It basically holds true for the SD plugin.



Again, read the installation section of the mc2xml plugin. It won't be nearly as complicated for the SD plugin, but you will have to reconfigure your video sources to hook them up to the new EPG listings. Uninstalling will also require some manual edits to the Sage.properties file (also discussed in the mc2xml plugin docs). These manual steps can't be avoided because of how plugins have to hook into the core to modify the EPG source.

Once you set things up, it's all good and will look and feel just like the current Sage EPG, except for some of the missing features (season/episode numbers, etc.). Updates to the plugin are seamless - just click and install the plugin update. The few minor manual steps are only required at initial install and during an uninstall.

[Fuzzy]

Originally Posted by mkanet

Thanks so much for the link Slugger.

I didnt see "First Run" as one of the missing features. Maybe it goes without saying that it's not missing? My favorites completely depend on that data being accurate.

Is there any way to supplement the missing features using "groovy scripting" if I get the "licensed version"? I'm guessing that's why this enhancement was added and documented in the first place. Is Groovy scripting some form of web scraping?

"Ability to pull in additional EPG data from other sources to supplement or correct/update the available EPG data through the use of Groovy scripting**"

Thanks for all your effort!

Groovy scripting is basically a scripting language. You can really program it to do anything, but it does take some work to figure out. You can, for instance, alter some information that is often incorrect in your listings (Slugger's example fixes some missing HD flags on his fox stations). You might even be able to have a script taht looks up detailed information from thetvdb.com to fill in season and episode numbers and such (though in my mind, it'd be easier to just use BMT to get that information). There are pros and cons to having it scripable.. pros: it can be made to do pretty much anything. cons: it's a new programming language to most, and would take quite a bit of work to make it do what you want.

[Slugger]

Originally Posted by mkanet

Thanks so much for the link Slugger.

I didnt see "First Run" as one of the missing features. Maybe it goes without saying that it's not missing? My favorites completely depend on that data being accurate.

Is there any way to supplement the missing features using "groovy scripting" if I get the "licensed version"? I'm guessing that's why this enhancement was added and documented in the first place. Is Groovy scripting some form of web scraping?

"Ability to pull in additional EPG data from other sources to supplement or correct/update the available EPG data through the use of Groovy scripting**"

Thanks for all your effort!

Yes, you can write groovy scripts to filter/massage/edit/add channels, shows, airings, and lineups dynamically to your lineup with each EPG update.

Originally Posted by Fuzzy

Groovy scripting is basically a scripting language. You can really program it to do anything, but it does take some work to figure out. You can, for instance, alter some information that is often incorrect in your listings (Slugger's example fixes some missing HD flags on his fox stations). You might even be able to have a script taht looks up detailed information from thetvdb.com to fill in season and episode numbers and such (though in my mind, it'd be easier to just use BMT to get that information). There are pros and cons to having it scripable.. pros: it can be made to do pretty much anything. cons: it's a new programming language to most, and would take quite a bit of work to make it do what you want.

Pro: You now have an option to directly modify the EPG data before the Sage scheduler processes it. This is an infinitely powerful ability, imho.

It's a bit of work, yes, but the way I figure it, it's at least an option - and a very flexible one at that.

Groovy scripting is so similar to Java that they're basically one in the same. As a matter of fact, most any .java file that can be compiled by the Java compiler should be executed by the Groovy engine with zero modifications.* So if you know Java, you know Groovy. If you don't, Groovy is a lot more forgiving than Java - since it's a dynamically typed scripting language - and is relatively easy to pick up.**

My latest project in this area is to modify the EPG listings directly to mark NHL games known to be blacked out in my area as "Blacked Out" in the title so it cannot match my favourite rule. No need to hack out other scripts that mark some airings as don't like, etc. Instead, I tackle the problem right at the source. Makes things 1000x easier to handle. I'll probably add the script as another example to the wiki doc when I'm done.

* I'm sure there are exceptions to this rule, but they'd be few and far between, certainly not an issue for anything you'd want to do in this context.

** I suppose this is a rather subjective statement and is relative to one's coding abilities. I found it rather easy to pick up in a short amount of time.

[Slugger]

Originally Posted by mkanet

Thanks so much for the link Slugger.

I didnt see "First Run" as one of the missing features. Maybe it goes without saying that it's not missing? My favorites completely depend on that data being accurate.

Forgot this one, yes first run status is handled just fine. Sage bases this flag on the original airing date of the show, which is provided in the SD (and mc2xml) data feeds.

[mkanet]

Thanks for explaining. It looks like I was right that it's powerful enough to supplement any missing feature. I actually thought this was in place for the developers (whoever will maintain this plugin) to add back missing features or fixing general problems with SD for everyone to use. I guess that was just wishful thinking. Don't get me wrong through, I am still VERY grateful for having this EPG with or without groovy scripts though!

Originally Posted by Slugger

Yes, you can write groovy scripts to filter/massage/edit/add channels, shows, airings, and lineups dynamically to your lineup with each EPG update.

Pro: You now have an option to directly modify the EPG data before the Sage scheduler processes it. This is an infinitely powerful ability, imho.

It's a bit of work, yes, but the way I figure it, it's at least an option - and a very flexible one at that.

Groovy scripting is so similar to Java that they're basically one in the same. As a matter of fact, most any .java file that can be compiled by the Java compiler should be executed by the Groovy engine with zero modifications.* So if you know Java, you know Groovy. If you don't, Groovy is a lot more forgiving than Java - since it's a dynamically typed scripting language - and is relatively easy to pick up.**

My latest project in this area is to modify the EPG listings directly to mark NHL games known to be blacked out in my area as "Blacked Out" in the title so it cannot match my favourite rule. No need to hack out other scripts that mark some airings as don't like, etc. Instead, I tackle the problem right at the source. Makes things 1000x easier to handle. I'll probably add the script as another example to the wiki doc when I'm done.

* I'm sure there are exceptions to this rule, but they'd be few and far between, certainly not an issue for anything you'd want to do in this context.

** I suppose this is a rather subjective statement and is relative to one's coding abilities. I found it rather easy to pick up in a short amount of time.

[Fuzzy]

Well, if someone, for instance, writes a script to grab season/episode numbers from another source, it's very easy for them to share it with the community (just drop the .groovy file into the proper script folder).

[NetworkGuy]

Doesn't BMT get the Season / Episode number? Would that work?

[Slugger]

Originally Posted by NetworkGuy

Doesn't BMT get the Season / Episode number? Would that work?

BMT does for recordings, after the recording has completed. You would not have S/E info for airings prior to them being recorded.

With that said, I have a solution that adds S/E data to the EPG by grabbing it from thetvdb.com. I'm currently using it with my mc2xml EPG plugin. Assuming I eventually move it from testing into the main code base of mc2xmlepg then I'd probably also port it to this plugin at some point.

It is worth noting, however, that I don't really plan on doing any more dev work on this EPG plugin until I'm fairly certain I'd actually be able to release it. As it stands, the mc2xml EPG plugin does everything I need and so I may never actually need/use this plugin on my system. If that turns out to be the case then this plugin will die.