Plugin: Schedules Direct EPG (not for v9)

[Slugger]

Looks like you have duplicate jars in the classpath, but anyway I'm working on the next release here this morning before work. Be sure to upgrade and check/correct any duplicate jars as describe in the next post I make.

[Slugger]

Fix 7 of the 0.0.6 release has been uploaded.

All users should move to this version immediately. Anyone still running 0.0.5.x will lose connectivity with the SD service within the next few days as Schedules Direct has announced that the servers running that version will be shutdown (they stopped updating the EPG data on that version a week or two ago anyway).

Support for 0.0.6.x is restricted exclusively to this new version. If you're not running 0.0.6.7, I can't help you.

For those upgrading from any older version:

So I've discovered a bug in the Sage Plugin Manager. It does not like renaming of files between releases. So for the last time, I've renamed the api jar, but this will require some manual intervention. After you upgrade, you will need to stop SageTV, go to your JARs folder in a command window and ensure there's nothing extra around (I can almost guarantee there will be).

This is what it should look like after you upgrade and clean things up:

C:\Program Files\SageTV\SageTV\JARs>dir sd*

 Directory of C:\Program Files\SageTV\SageTV\JARs

05/30/2014  08:12 AM           206,071 sdepg.jar
05/30/2014  07:53 AM            95,479 sdjson-api.jar
               2 File(s)        301,550 bytes

(File times are EDT.)

You will probably have an extra file named sdjson-api-0.20131021.2-SNAPSHOT.jar. Delete this file (or any others that look like). I've modified my build scripts such that the api jar file will always be renamed to the generic name above, which should eliminate the duplicate jars in the classpath issue going forward.

Please make note of the new recommended default config settings as outline in the release notes for the plugin. I've pasted them below for reference. Users who are upgrading should make the modifications in the plugin settings. New users will have these defaults set for you.

UPGRADE NOTES
 
Users who are upgrading should modify their plugin settings as follows:
 
* Base sdjson URL: https://json.schedulesdirect.org
 
* Max Schedule Request for sdjson: 250 (was 1000)
 
* Max Program Request for sdjson: 5000 (was 50000)

Everyone is encouraged to upgrade asap as this release marks the end of my annual personal project cycle. Basically, I'm on "vacation" from my various personal tech projects until sometime after Labour Day. You've got about a week or so where my head will still be in this and so if you've got issues getting the latest version running, now is the time to ask for help. After that, I'm still around, I'll still answer questions, but the response times will be slower & slower. I'm also away on an actual vacation in early July for a week and another towards the end of July so there will be no responses during that time.

For those unaware, my annual "vacation" period usually runs the summer into Sep/Oct. What this means is I stop developing in all my personal projects. I still tinker on rainy days, but there are no scheduled releases. I'm around to answer questions as needed, but expect slower response times, or no response for days when I'm on my actual vacation days. Major bugs that are discovered will continue to be addressed and fixed as needed, but minor bugs that don't affect core functionality will be logged for the fall. Feature requests are logged for the fall. Basically, if some nasty bug is discovered that affects EPG data, I'll fix it and do a release -- after all I do use this plugin on all my systems for EPG data, but otherwise, I basically shutdown Eclipse and try to enjoy the warm weather.

[osx-addict]

Originally Posted by Slugger

Looks like you have duplicate jars in the classpath, but anyway I'm working on the next release here this morning before work. Be sure to upgrade and check/correct any duplicate jars as describe in the next post I make.

You mind if I ask how you determined that from the stackdump? If that's the case and the jars are not stored in the SageTV\jars directory (IIRC), is there any other place I should be looking? I monkeyed around with it last night and ditched my wiz.bin and the sage.properties file and the issue persisted which may indicate that you're spot on.. The last thing I was going to try if nothing else pans out is to nuke the entire SageTV installation but I REALLY do not want to go there if I don't have to..

[Slugger]

The exception being thrown is InvalidHttpResponse, but that's old. I renamed that class in later builds, which tells me you still have an old jar in the classpath, probably along side the newer one. See the post about the new release today, it will tell you how to clean up duplicate jars in the classpath.

I can't stress this enough to everyone, you do not need to blow away your Sage installation to get this plugin running. Blowing away wiz.bin is useless, it will not fix any error ever generated by this plugin (because no plugin has direct access to wiz.bin). Reinstalling Sage is just not necessary. Any error logged by this plugin can always be fixed without the need to reinstall SageTV, always. Blowing away Sage.properties is unnecessary. The only parts that affect this plugin are discussed in the upgrade wiki. Toasting off the rest of that file is just creating more work for yourself to restore those settings and it's not going to fix issues you may be having with this plugin.

Follow the user's guide and the upgrade wiki (if applicable). If you hit errors, report them here and I'll do my best to get them fixed. Now that everyone's moving to 0.0.6.7, I don't have to worry about who's running what jars, making my life a lot easier when trying to debug issues. The biggest cause of errors is usually duplicate jars in the classpath. To be clear, what I mean by this is two or more uniquely named jars in the classpath providing the same class files. This is bad news in a java app.

sdjson-api.jar
sdjson-api-0.20131021.2-SNAPSHOT.jar

If both of those files exist in your SageTV\JARs\ folder then you will have problems. They both provide different versions of the same classes and Java will just use the first version of a class file it finds. Worst case, Java grabs a version of a class from one and a different class from another and they aren't compatible, which will crash the app (and/or JVM) at runtime -- and actually this scenario is the easiest to diagnose because a crashing JVM with a class mismatch exception is pretty self explanatory. But usually what happens is the old version of a class gets loaded and used and it's fine/compatible, except you end up using older code that still contains bugs that have been fixed in the newer jar. Then devs get confused when you report a problem that they know was fixed and then the chase is on to find the classpath conflicts.

So anyway, read the post above about how to detect these duplicate jars and clean them up.

[rdefino]

Originally Posted by Slugger

Did you just enable those channels today? A bug at the SD service means that all epg downloads would have failed since 7am yesterday. The bug was fixed earlier today for tomorrow's SD data load and so data pulls should start working again tomorrow. So any new channels you may have enabled over the last day or two would not have been able to pull in data, but will be able to starting tomorrow (maybe even later today, check the SD status page in the webui).

Hi Slugger, I enable them Wed night and just did a refresh of the epg from the plugin. Still the pay channels have no data. really strange.

[Slugger]

That debug web page I sent you the other day... run it again and email me the output. I suspect you haven't mapped HBO to the proper SD stationid.

[osx-addict]

Originally Posted by Slugger

The exception being thrown is InvalidHttpResponse, but that's old. I renamed that class in later builds, which tells me you still have an old jar in the classpath, probably along side the newer one. See the post about the new release today, it will tell you how to clean up duplicate jars in the classpath.

Thanks for the prompt reply.. I'm fairly certain after I uninstalled the plugin completely (after several restarts to get rid of dependencies), that I looked in the jars directory and noted that no sd*.jar files existed but will check again this evening...

I can't stress this enough to everyone, you do not need to blow away your Sage installation to get this plugin running. Blowing away wiz.bin is useless, it will not fix any error ever generated by this plugin (because no plugin has direct access to wiz.bin). Reinstalling Sage is just not necessary. Any error logged by this plugin can always be fixed without the need to reinstall SageTV, always. Blowing away Sage.properties is unnecessary. The only parts that affect this plugin are discussed in the upgrade wiki. Toasting off the rest of that file is just creating more work for yourself to restore those settings and it's not going to fix issues you may be having with this plugin.

Agreed and that IS my goal -- it's just a lot work to blow away sage and start over and I will NOT do that unless I'm out of options -- and we haven't had a usable sage for several days which of course is NOT your problem but I do know my wife would like to watch some TV again

[rdefino]

Originally Posted by Slugger

That debug web page I sent you the other day... run it again and email me the output. I suspect you haven't mapped HBO to the proper SD stationid.

Here it is. Let me know if you need more logs. thanks

Also, it's all the pay channels. Hbo, shotime, cinemax, etc..

[Slugger]

Actually I was looking for the web output from that web page I had you install: debug.gsp

[rdefino]

Oh, ok. I put the output in a text file. Let me know if its good enough, thanks.

[Slugger]

That's too hard to read. Save the file as html and send me that, please. While you're at it, put the latest sdjson.epg file up on dropbox as well and put all the log settings for the plugin to debug and run it again and zip up the logs. There's also a stations.txt file in the sdepg folder, send that along, too, please.

[rdefino]

Just sent them to you personal email.

thanks

[osx-addict]

Still not working -- got the plugin updated and when I manually refresh I get the following :

2014-05-30 19:09:20,352 WARN [Plugin]: Failed to dispatch button event for: sdepg/refresh to method refreshEpgData in class sagex.epg.schedulesdirect.plugin.Plugin
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sagex.plugin.AbstractPlugin.fireButtonClick(AbstractPlugin.java:442)
at sagex.plugin.AbstractPlugin.setConfigValue(AbstractPlugin.java:412)
at sage.e.w$49.void(Unknown Source)
at sage.az.a(Unknown Source)
at sage.a.m$b.a(Unknown Source)
at sage.a.m.a(Unknown Source)
at sage.e.a(Unknown Source)
at sage.be.a(Unknown Source)
at sage.be.a(Unknown Source)
at sage.be.null(Unknown Source)
at sage.be.for(Unknown Source)
at sage.cb.char(Unknown Source)
at sage.EventRouter.a(Unknown Source)
at sage.EventRouter.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.schedulesdirect.api.exception.JsonEncodingException: Request did not return expected content type!
at org.schedulesdirect.api.json.JsonRequest.submitForJson(JsonRequest.java:141)
at org.schedulesdirect.api.NetworkEpgClient.authorize(NetworkEpgClient.java:226)
at org.schedulesdirect.api.NetworkEpgClient.<init>(NetworkEpgClient.java:200)
at org.schedulesdirect.api.NetworkEpgClient.<init>(NetworkEpgClient.java:173)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at sagex.epg.schedulesdirect.EPGImportPluginSchedulesDirect.getProviders(EPGImportPluginSchedulesDirect.groovy:119)
at sage.EPGImportPlugin$getProviders.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at sagex.epg.schedulesdirect.plugin.Plugin.forceEpgRefresh(Plugin.groovy:123)
at sagex.epg.schedulesdirect.plugin.Plugin.refreshEpgData(Plugin.groovy:155)
... 19 more
2014-05-30 19:09:20,352 WARN [Plugin]: Failed to handle ButtonClickHandler: 'sdepg/refresh' in class: sagex.epg.schedulesdirect.plugin.Plugin

[Slugger]

So rdefino's problem has been identified as a bug in the plugin code. Another fix release will be done sometime soon. Looks like my vacation has been delayed.

@osx-addict In the plugin settings, set the sdjson capture setting to 'ALL', reproduce the error, then zip up everything in SageTV\plugins\sdepg\capture\ and SageTV\plugins\sdepg\logs\ and send it my way, please.

[BobbyDing]

Slugger,
I ran the upgrade, exited sage and found and deleted the sdjson-api.SNAPSHOT file. The new sdjson-api with the date of 5-30 and a size of 94kb was there. However there is an sdepg.jar there with a date of 5-15 197kb, and an sdepg.jar.114 dated 5-30 at 202kb. Which one of these do I want? Or don't I want either?

Thanks,

Bobby

[osx-addict]

ok -- finally got somewhere -- but now when it prompts to enter your cable or satellite provider the list is empty and I'm stuck -- I even did a fresh install of Sage and the same behavior occurs.. ugg..

IF it matters I'm using HDHomeRun tuners with OTA only..

PS. I tried doing the capture but sage would get hung up and create NO logs -- NONE -- After about 5 minutes of waiting I just killed it -- tried again with the same results..

[Slugger]

@BobbyDing You want the one from May 30. See here. It needs to be renamed sdepg.jar and remove the others.

@osx-addict If your provider list is empty then you likely need to register your lineups with the json service. The Schedules Direct web site means nothing as far as lineup registration is concerned. You either need to register your lineups via the Sage webui or via the command line as outlined here. If logs weren't being written then maybe you're running out of disk space? If so, that's going to cause all kinds of weirdness. Regardless of the settings, sdepg should be writing some level of minimal logging to the SageTV\plugins\sdepg\logs\ directory. If not, then something weird is going on and then you need to start focusing on the Sage debug log for answers. Lineup types don't matter, just be sure your lineups are registered with the json service as described in the link a few lines above this one. We're getting close to the point where if you have the ability to remote desktop into your Sage box, I can take a look around to see what's going on. That won't happen today (unless you happen to reply in the next hour) as I'm heading out for the day here shortly, but maybe something to consider.

[BobbyDing]

Working. Thanks!

[gdippel]

Time Warner Cable will be completely redoing their channel lineup as of June 3. I noticed my epg data is not reflecting this change and checked the Schedules Direct site and discovered they have a new lineup for my area, Queens, New York. I left them a ticket inquiring whether there would be a new headend that I would have to register. No response as of yet, due to the weekend I suppose. Now, however, when I try to check available headends via the web ui, I get no results. I currently have 2 headends registered. Before the plugin update, I would get a complete listing of headends for my area for all providers. Any thoughts?

[Slugger]

SD changed the search format in the new release of the json service. The country is now a three letter search term (it was 2 before). So use 'USA' instead of 'US' to search ('CAN' instead of 'CA' for Canada, etc.). Ticket 17 opened for this issue; I will attempt to get this fix into the final fix release before vacation.