Add support for tuning plugins written in Java

[enternoescape]

There are many tuning methods currently that either rely on running an executable or performing specific actions on an IP address. While there are plugins for Windows and Linux that support the case of an executable which can then also be used to perform an IP address oriented solutions, it's very challenging for non-tech savvy users to configure these plugins correctly.

I am working on an interface that can be used for this purpose and will allow normal plugins to register and unregister tuning plugins. The interface distinguishes between different devices by an integer ID so that it's completely compatible with how tuning is currently done. Plugins are determined to be Java instead of SFIR by checking a map of the registered Java tuner plugins. If it's not on the map, it's assumed to be SFIR. The API can also resolve the device ID to a more descriptive name as provided by the plugin. This gets around what would otherwise be a very limiting level of descriptiveness for Java based tuning devices.

My thoughts are that the Java tuning methods can be mixed with the SFIR plugins in the UI and if the plugin name matches the Java tuning plugin name when selected, it allows you to select a device from a list of the device ID's resolved to descriptive strings as provided by the plugin. If the list is empty, it will tell you to configure the associated plugin. I think it would be nice for that to go one step further and allow you to go directly to the plugin configuration from there, but I don't see how a plugin interface can find itself. SageTV wraps the plugin, so at least from what I've seen, you'd have to get all of the plugins and then find the one that matches your plugin or is there a much easier way to do this?

[CraziFuzzy]

I was looking at this as well, and the whole SFIR implementation is so different than the way just about anything else in sage is built. It really sort of needs a much more extensive rewrite, to be able to handle things smoother, and the existing SFIR plugins perhaps wrapped up into a pre-installed class in the new implementation.

That said, I'm wondering if plugins are really the best option for this - I mean - now with it an open source project, is there any problem with new tuning methods going forward being included in the core product? My interest in this area was to implement the UPnP based tuning recently discovered for Dish Network boxes - would it really be a problem if Dish/Echostar Network Tuning was always present in the options list?

[enternoescape]

I don't think the SFIR implementation needs to be re-written, but there's no reason why the current plugins couldn't be loaded and used from within the new implementation.

I feel like this an obvious application for plugins. There are always going to be niche products that only a few people actually use and it doesn't make sense to have every possibility in the core product. The niche implementations will likely only grow if they can be written in Java. Your example is really one of the only exceptions to this rule that I can think of. Anything else really should only be on the list because a plugin was loaded that implements it.

[stuckless]

When I started to work on gentuner, my first instinct was to create a
"native" tuner interface that would simply call back to java... since
managing this in Java would be so much simpler. Now that SageTV is open
source, I think that it would be good to offer tuning solutions that java
specific and don't rely on a native piece of code, at all.

I also think that the offering tuning plugins as an actual plugin is a good
idea as well. There might very be some "core" ones, although not sure
which ones we'd want to include as core. For example showing me a "Dish
Network" tuning option has no value to me, so should that be "core" or
separate plugin that you install.

I think that IF you start enabling tuning methods as plugins... should the
"step by step wizzard" allow you to select and install them from that part
of the setup? It would make sense to me if it did.

And, what's SFIR? I googled it, but nothing came back. You both appear
to understand it very well... But I've never heard of it :)

On Mon, 31 Oct 2016 at 07:33 Joseph Shuttlesworth notifications@github.com
wrote:

I don't think the SFIR implementation needs to be re-written, but there's
no reason why the current plugins couldn't be loaded and used from within
the new implementation.

I feel like this an obvious application for plugins. There are always
going to be niche products that only a few people actually use and it
doesn't make sense to have every possibility in the core product. The niche
implementations will likely only grow if they can be written in Java. Your
example is really one of the only exceptions to this rule that I can think
of. Anything else really should only be on the list because a plugin was
loaded that implements it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#202 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABAfKUiZyOMvzZye4uWM-ejS32KB7sHlks5q5dH_gaJpZM4KkmoM
.

Sent from Android

[enternoescape]

SFIR is referring to the reference DLL that all of the current tuning plugins are modeled after. Check out sage/SFIRTuner.java.

I plan to modify the default STV to add the Java based tuners to that list for selection so they will be just as easy as the current native ones to select from.

I did notice a little snag with accessing the SFIR plugins from within the new implementation. The problem has to do with retaining IR remote learning. I would have liked to make that more generic in nature so that SageTV could have a standard remote learning method in the interface, but maybe it makes more sense to let each plugin do this in it's own preferred way and not force a specific model on everyone. The only downside to not standardizing this would be then each developer if learning is needed will have to implement their own UI functionality for this. I suspect learning will be a fairly rare thing in a pure Java solution, but this is still worth mentioning.

[CraziFuzzy]

SFIR I believe stood for SourceForgeIR, it was a library/protocol they used apparently early on for IR support for basic UIRT devices.

I'm not against plugins being able to work - but as sean brought up, the issue with 'basic' functionality like this being tied to plugins, is that when new users are going through the setup wizard, those plugins are not installed yet (since the wizard runs before even reaching the main menu).

For retaining learning - if we genuinely wrote up a new 'remote' class, you could very well build 'learning' into it, as well as the ability to report that it has this capability to an overall RemoteManager class. It makes sense that some devices simply wouldn't support or even require learning, so having the options display on the menu is confusing. Regarding leaving the learning UI to each plugin, I cant' imagine there being much that can't be standardized. how varied do you envision learning a remote command would be?

I've never built a java class plugin, so I'm not entirely sure how they are implemented, but it seems that each would implement a standardized StubRemote, and when started, would register with the RemoteManager. This could very well include a SFIRWrapperRemote that would look for legacy SFIR style plugins and expose them via the same interfaces.

[jwittkoski]

The current tuner plugin native interface has some leftovers (examples: OpenDevice for talking to a serial port, FindCarrierFrequency for interfacing directly with IR devices and learning) that were specific to the devices SFIR supported originally and maybe aren't needed in a newer tuning interface.

I like the ideas of a new interface where plugins can specify what their capabilities are (learning, etc) and of providing a SFIR wrapper to support old "legacy" SFIR plugins.

Being able to optionally load non-core plugins during setup would make the user experience nicer too.

[Narflex]

I fully support doing this...go for it y'all. :)

[enternoescape]

Is everyone convinced that the plugin configuration page will be sufficient for configuring tuning plugins? One thought I had was that if you need to enter every single actual device due to a lack of any way to automate detection (maybe by IP address), how would that work in the plugin configuration dialog? Would it be a little clunky?

[stuckless]

I think that "plugin configuration" would only be good for configuring global information about a plugin. Tuner plugins would need to have multiple instances and those instances would be configured. ie, a single Dish IP Tuner plugin might need 3 different configurations if you ere tuning 3 different STBs. So, for this reason, I would not configure them in the plugin configuration.

It would be nice to have a declarative way to provide "remote" configurations for a plugin, so that each provider doesn't have to build a STV ui to do it. (ie, something like the current plugin configuration semantices, except for instances of a tuner plugin)

[Narflex]

Yeah, I was thinking you could just reuse what we have for plugin
configuration for this too. I'd be fine with making a whole new plugin type
for this that works with the current plugin system. I could do any server
side changes needed for that.

Then on the tuner setup page for that you could have an option to show the
other tuner plugins available so it could install them that way (or just
preinstall them all with the installer, skip the whole use of the actual
plugin system except for the config UI part).

Jeff Kardatzke
Sent from my Android

On Nov 2, 2016 8:44 AM, "Sean Stuckless" notifications@github.com wrote:

I think that "plugin configuration" would only be good for configuring
global information about a plugin. Tuner plugins would need to have
multiple instances and those instances would be configured. ie, a single
Dish IP Tuner plugin might need 3 different configurations if you ere
tuning 3 different STBs. So, for this reason, I would not configure them in
the plugin configuration.

It would be nice to have a declarative way to provide "remote"
configurations for a plugin, so that each provider doesn't have to build a
STV ui to do it. (ie, something like the current plugin configuration
semantices, except for instances of a tuner plugin)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#202 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANEIDJ38JE7i0YKHS_zXoleM3DFaMsrrks5q6K_2gaJpZM4KkmoM
.

[enternoescape]

That makes the most sense. I was thinking about creating a new plugin type for tuning plugins anyway and only showing them when then you actually would be interested in working with them will keep things a little more tidy. I presume "Tuner" would be an apt type name.

What I'm leaning towards is an interface that allows you to select from what is already available with a button you can select to see a list of tuning plugins available to download and install. You can then install whatever you need from the list and return to the selection to use the plugin you installed.

Selecting a tuning plugin takes you to a screen that presents you with all of the tuning profiles configured for that tuning plugin. The list can be automatically generated by the plugin or the user can create new profiles by selecting a create profile button. Old tuning configurations will be converted into profiles and a system message will be generated so the user is more aware that something important has changed. When selecting a profile the user will be presented with the options to use/configure/rename/remove the profile. All of these buttons with the exception of "use" will only be displayed if the tuning plugin allows for it via a permissions mask.

"configure" will show a screen similar to what you see when configuring a plugin. There is an added config type for infrared learning. It provides a button that leads into a dialog for learning and managing remotes. Since I don't think we should enforce any particular way to store infrared codes, there's an interface for management and learning that is up to the plugin to implement if it wants to support this kind of learning.

I'm trying to keep complexity down while keeping things fairly flexible, so I also created a helper class that tuning plugins can optionally get and use to manage both global and individual profile settings within Sage.properties. I'm at least a week away from UI work, but so far things are starting to look very usable.

Before I start diving into creating all of the new API methods, I was wondering about all of the old ones that will essentially be deprecated regarding SFIR. Once we start using profiles, even if you configure the device correctly using the old methods, when the capture device goes to tune, it's going to use the profile to tune which will likely not do anything if you never set one. Is there a precedent for deprecating API calls? I'm just wondering what approach is preferred. I suspect there are no plugins actually using the ones related to infrared which should make this easier for users.

[Narflex]

Can't you just make it support both the old and new style together? So this
would essentially be a whole new tuning plugin type of setup, and have all
its own things and the config settings in CaptureDeviceInput would signify
if it's the old or new style and call into it appropriately.

Jeff Kardatzke
Sent from my Android

On Nov 4, 2016 7:13 PM, "Joseph Shuttlesworth" notifications@github.com
wrote:

That makes the most sense. I was thinking about creating a new plugin type
for tuning plugins anyway and only showing them when then you actually
would be interested in working with them will keep things a little more
tidy. I presume "Tuner" would be an apt type name.

What I'm leaning towards is an interface that allows you to select from
what is already available with a button you can select to see a list of
tuning plugins available to download and install. You can then install
whatever you need from the list and return to the selection to use the
plugin you installed.

Selecting a tuning plugin takes you to a screen that presents you with all
of the tuning profiles configured for that tuning plugin. The list can be
automatically generated by the plugin or the user can create new profiles
by selecting a create profile button. Old tuning configurations will be
converted into profiles and a system message will be generated so the user
is more aware that something important has changed. When selecting a
profile the user will be presented with the options to
use/configure/rename/remove the profile. All of these buttons with the
exception of "use" will only be displayed if the tuning plugin allows for
it via a permissions mask.

"configure" will show a screen similar to what you see when configuring a
plugin. There is an added config type for infrared learning. It provides a
button that leads into a dialog for learning and managing remotes. Since I
don't think we should enforce any particular way to store infrared codes,
there's an interface for management and learning that is up to the plugin
to implement if it wants to support this kind of learning.

I'm trying to keep complexity down while keeping things fairly flexible,
so I also created a helper class that tuning plugins can optionally get and
use to manage both global and individual profile settings within
Sage.properties. I'm at least a week away from UI work, but so far things
are starting to look very usable.

Before I start diving into creating all of the new API methods, I was
wondering about all of the old ones that will essentially be deprecated
regarding SFIR. Once we start using profiles, even if you configure the
device correctly using the old methods, when the capture device goes to
tune, it's going to use the profile to tune which will likely not do
anything if you never set one. Is there a precedent for deprecating API
calls? I'm just wondering what approach is preferred. I suspect there are
no plugins actually using the ones related to infrared which should make
this easier for users.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#202 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANEIDHIPY0PGP87c_064DvHGt1DcU1kyks5q6-ZJgaJpZM4KkmoM
.

[CraziFuzzy]

Does this really require a new plugin type? Wouldn't the library plugins work alone? or is there no way to search for classes that inherit a certain type?

[Narflex]

I think it would be cleaner to have its own plugin type. Then they can be
more easily identified for selection from the UI.

Jeff Kardatzke
Sent from my Android

On Nov 6, 2016 9:03 PM, "Christopher Piper" notifications@github.com
wrote:

Does this really require a new plugin type? Wouldn't the library plugins
work alone? or is there no way to search for classes that inherit a certain
type?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#202 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANEIDAmjCX8tJVzIv2TXIjJxPbcDDMWjks5q7rEWgaJpZM4KkmoM
.

[enternoescape]

I can leave the old plugins as their own thing, I just thought it would be less confusing if there wasn't any visible difference between what is old and what is new to the user. It was brought up to place the old plugins in a wrapper to allow use within the new plugin architecture. I don't need to do this of course and it would make things a little easier for me from the code-side of things. I was really thinking more about the end user and the confusion that will arise when some plugins do configuration one way and other plugins do it another way. If we pull the old plugins into a wrapper, we can present them through the same interface as the new plugins and eliminate that confusion completely.

@Narflex I can of course just create the new tuning plugin API and provision for the existence of both types of plugins, then the legacy plugins could be adapted at a later date if desired. It sounds like this approach is more in line with what you have in mind.

[Narflex]

I wouldn't worry about confusion with different types of config UIs for
different tuning plugins. Most people will likely just use one plugin and
never even see that.

And the way I'm thinking about it, they'd all just show up in the current
tuning plugin selection list...with some kind of var in the UI code to
signify which is which, along with another button probably for installing
new plugins at that point. Then the UI forks after that.

Jeff Kardatzke
Sent from my Android

On Nov 7, 2016 6:13 AM, "Joseph Shuttlesworth" notifications@github.com
wrote:

I can leave the old plugins as their own thing, I just thought it would be
less confusing if there wasn't any visible difference between what is old
and what is new to the user. It was brought up to place the old plugins in
a wrapper to allow use within the new plugin architecture. I don't need to
do this of course and it would make things a little easier for me from the
code-side of things. I was really thinking more about the end user and the
confusion that will arise when some plugins do configuration one way and
other plugins do it another way. If we pull the old plugins into a wrapper,
we can present them through the same interface as the new plugins and
eliminate that confusion completely.

@Narflex https://github.com/Narflex I can of course just create the new
tuning plugin API and provision for the existence of both types of plugins,
then the legacy plugins could be adapted at a later date. It sounds like
this approach is more in line with what you have in mind.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#202 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ANEIDLYg6LA4bUw1T48tgbkWSwJ4GoLeks5q7zIXgaJpZM4KkmoM
.