Can't configure inputs with EPG plugin

[Slugger]

Andy's been working on getting the Schedules Direct plugin to work with OSS version. He got me the code changes, I managed to build it, and just as a final sanity check before submitting it to the repo I created a vm for v9 and tried to setup some inputs using the plugin. This is on linux with no server key installed (i.e. a new OSS user with no license keys available to her).

All looks good until you select the lineup to attach to the input. The next step is it tries to download the lineup from the epg server, but instead of using the configured epg plugin, it always tries to use the Sage epg server, which halts the whole operation as it immediately dies "You do not have a SageTV license, you cannot download EPG data."

I've spent more than my allotment of summer time coding looking at this over the last couple hours and I've traced it down to this:

CaptureDeviceInputAPI.java:454

Seems when configuring a new input, we end up in this else block because there is no "custom_data_source_class" defined and the first thing that else block does is create a new WarlockRipper (i.e. head straight to the Sage epg server), which then immediately bails since there is no sage license defined.

So what is an EPGDataSource and what is its role? It appears that epg plugins must provide a custom one along side the epg plugin implementation? This EPGDataSource is new to Sage 9 (as far as I can tell). I certainly didn't have to provide any such custom class for the v7 version of the plugin.

A quick peek thru EPGDataSource suggested I could probably just fake one of these things to bypass the WarlockRipper instantiation, but I figured it was best to wait for Jeff's explanation (and I really don't want to code all day to test my theory ).

Good news out of this though is I now have a Sage v9 vm setup, but just not quite ready to dive into OSS projects too heavily yet.

Bad news: This EPGDataSource thing seems to suggest that all v7 (and older) epg plugins are broken in v9 (at least when the user has no server license available). Please correct me if my statement is wrong.

Andy, Jeff's answers to my findings are probably going to create a whole bunch more work for you to get this plugin working in Sage 9. If a custom EPGDataSource can just safely return hardcoded values for the public methods then it may not be too bad, but if these things have actual meaning and need to return values based on "stuff" then, well, there's some work to be done.

[Fuzzy]

Weren't you originally using some workarounds in the v7 version that were 'patched' in v9, causing this issue to begin with? I think part of that 'fixing' was changing all datasources to be a similarly built class. That's sort of what this is doing, it uses the datasource class, or if there isn't one configured, it else's into using the 'default' warlaockripper.
I honestly had thought building a class to wrap around the schedules direct was primarily what was being done.

[Slugger]

My original workaround simply dealt with the fact that the EPGDBPublic2 interface was incorrectly obfuscated in the 7.1.9 Sage.jar. That interface provided the ability for epg plugins to do things like set the new (at the time) live flag and other epg additions added by that interface. Turns out the code changes required to the plugin to handle this were minimal -- I planned for this day to come (where the class would no longer be obfuscated, not necessarily an OSS release per se) and my plan worked exceedingly well. So undoing my wrapper and referring directly to the Sage interface was super easy; delete my wrapper from the project and change 2 or 3 lines of code to use the Sage interface instead of my wrapper class and then change constant references from my wrapper to the equivalent in the EPGDBPublic2 interface, that's it. But with those changes built, that lead to this EPGDataSource issue.

The EPGDataSource class is completely new to v9 (as far as I can tell). CaptureDeviceInputAPI makes reference to this new custom_data_source_class property from Sage.props, which doesn't seem to exist in v7 (at least not in my v7 props file). If this class isn't new then v7 did a much better job of dealing with it on behalf of epg plugin implementations. I'm pretty sure it's new and I'm pretty sure epg plugins will have to provide a custom implementation of this class along side their epg plugin class, but I'll wait for Jeff to confirm -- no desire to spend a day experimenting on Sage 9 stuff yet.

[Fuzzy]

I'm just glossing through it for the first time, but I think this EPGDataSource class is in lieu of the old EPGPlugin interface. It looks like everything is done in the datasource, and the EPGPlugin is instead called by warlockRipper to add/modify data in between warlock and the database. I don't think you'd need both, a SchedDirectDataSource class implementing ETGDataSource should be able to handle all of the SchedulesDirect duties (if I'm understanding it's implementation properly).

[Narflex]

EPGDataSource has always been there...the stuff you see in the code about the custom class is new and is there for testing that I do sometimes with an alternate EPG server.

I submitted a patch to GitHub this morning that fixes the problem with the EPGPlugin class not getting invoked if there was no SageTV license. Just an oversight on my part when i added that code...trivial fix.

[Slugger]

The patch seems to work fine. With it, I'm able to configure the inputs and load the epg via the plugin.

I'll package up the plugin and get a v9 version into the repo when I have time this week (most likely this weekend-ish).

[tmiranda]

Originally Posted by Slugger

The patch seems to work fine. With it, I'm able to configure the inputs and load the epg via the plugin.

I'll package up the plugin and get a v9 version into the repo when I have time this week (most likely this weekend-ish).

Thanks Slugger. This is going to make a lot of people happy

[Slugger]

Finding some long standing bugs that are much easier to track down when you can mod the core to dump full stack traces.

Good news, I'm going to fix them... bad news, this is going to delay the release by an unknown amount of time. All the bugs I'm hitting are with a fresh install with unconfigured inputs, which is how the typical OSS user is going to try to setup this plugin so I figure I'll save myself the Q&A session and fix what I can ahead of time.

ETA: unknown, but if not by Friday morning then probably not until the following weekend (long weekend this week so won't be around).

Edit: I found the underlying bug causing all the other weirdness and fixed it! A release will be made before I leave for the weekend. See the other thread for more details.