Standard plugin configuration and event handling - How?

[hingsten]

I've got a Standard plugin working, but I'm having the following issue. My setup is SageTV 7.0.11 running as a Windows service and I'm enabling the plugin and a Library dependency to be installed through the use of a local SageTVPluginsDev.xml file.

If I declare the plugin as a Desktop plugin:
- It fails on initial install/restart as necessary configuration is missing (third party login details)
- There is no automatic configuration screen created for the plugin settings
- Once I have manually added the settings to SageClient.properties and restarted Sage or re-enabled the plugin, it works like a charm

If I declare the plugin not to be a Desktop plugin:
- It succeeds on initial install/restart
- There is an automatic configuration screen created for the plugin settings
- The "sageEvent" event handler method is never fired rendering the plugin useless

Is there a way to have it both ways - to have an automatic configuration screen created and to have the event handling working properly?

I have tried registering the plugin implementation class as an event handler using the SageTVPluginRegistry instance that is passed to its constructor as well as the ways of getting a SageTVPluginRegistry instance using GKusnickToolsLib, but without success.

Alternatively, instead of trying to make it work as a non-Desktop plugin (just to get the automatically created configuration screen) is the solution to make an additional STVi plugin in order to provide a configuration screen? Or, just forget about a configuration screen.

Thanks in advance for any help you can provide. I'm sorry if I've overlooked something simple - I'm pretty new to this.

[Fuzzy]

You might try putting some error handling in your code to handle the properties NOT existing. Of course, then your plugin would not function until configured. As for forcing the plugin screen to come up before starting the plugin, that feature has been discussed/requested, but doesn't currently exist.

[GKusnick]

With Desktop == false, Standard plugins run in the service process. With Desktop == true, they run in the UI process. Pretty much the only reason to run your plugin in the UI process is if it needs access to per-client UI state such as walking the widget tree or issuing calls to SageCommand(). Note that Desktop plugins don't work on Placeshifter or extender clients (or on Linux, since it has no desktop client).

If the plugin runs in the service process (Desktop == false), then it will respond to events fired by the service (e.g. DB updates), but not to events fired by the UI (e.g. playback started/stopped) since those happen in a different process. However I believe there may be a third-party library for forwarding client-side events to server-side plugins, but I don't know the details of that.

What events in particular are you trying to handle? More generally, what does you plugin do that might make it more suited to running in the UI rather than in the service (or vice versa)?

As far as I know there's no reason why a Desktop plugin can't have a configuration screen. You should not need to code your own config UI as a separate STVI. However there were some bug fixes in 7.0.12 related to Desktop plugins so you might want to give that a try to see if that solves your problem.

[tmiranda]

And the SageTVPluginsDev.xml file ALWAYS goes on the server, even if you have declared your plugin as a client plugin. If you do not do that the sageEvents will never fire.

[hingsten]

Thank you all for your responses. They were very helpful.

Originally Posted by Fuzzy

You might try putting some error handling in your code to handle the properties NOT existing.

I've currently got code that throws runtime exceptions in the plugin's constructor, but will change it not to throw any exceptions and to also not handle any events until properly configured. Perhaps this is why the automatic configuration UI didn't show up. I guess I'll find out...

I'll make sure the plugin's Description has a note on how to configure it unless I can get the automatically created configuration screen to work.

Originally Posted by GKusnick

With Desktop == false, Standard plugins run in the service process. With Desktop == true, they run in the UI process.

If the plugin runs in the service process (Desktop == false), then it will respond to events fired by the service (e.g. DB updates), but not to events fired by the UI (e.g. playback started/stopped) since those happen in a different process.

What events in particular are you trying to handle? More generally, what does you plugin do that might make it more suited to running in the UI rather than in the service (or vice versa)?

That makes sense to me now. As I'm handling PlaybackStarted and PlaybackFinished it sounds like I'll need to be a Desktop plugin.

Originally Posted by GKusnick

As far as I know there's no reason why a Desktop plugin can't have a configuration screen. You should not need to code your own config UI as a separate STVI. However there were some bug fixes in 7.0.12 related to Desktop plugins so you might want to give that a try to see if that solves your problem.

I'll give 7.0.12 a try. Thanks for the heads up!

Originally Posted by tmiranda

And the SageTVPluginsDev.xml file ALWAYS goes on the server, even if you have declared your plugin as a client plugin. If you do not do that the sageEvents will never fire.

That's good to know, too. Thanks!

I'll play with this some more over the next few days and post my findings.

[tmiranda]

Originally Posted by tmiranda

And the SageTVPluginsDev.xml file ALWAYS goes on the server, even if you have declared your plugin as a client plugin. If you do not do that the sageEvents will never fire.

I should probably clarify this - some events will never fire. Events that effect the server (like adding favorites, deleting mediafiles) will not fire.

[Slugger]

Starting with 7.0.12, the various Playback events on a client DO fire in the server process with the UIContext variable set. With this addition, all events fired by a client can now be listened for and handled by the server.

[tmiranda]

Thanks, I didn't realize that was changed.

[hingsten]

I might have had my SageTV terminology wrong as far as what a client really is. These are my latest findings.

If I install my plugin using the SageTV.exe "client" on the same machine where the SageTV Windows process is running, I get no Configure Plugin option but I do get a Reset Plugin Configuration option.

If I install my plugin using the SageTVClient.exe client on a remote machine, I get a Configure Plugin option as well as a Reset Plugin Configuration option for the client plugin installation. Looking at the server plugin installation from this client it still only shows the Reset Plugin Configuration option.

Unless this is a defect or there is a way around it, I will settle for configuring the plugin manually in SageClient.properties on the server and do it through the client interface for each client.

[GKusnick]

In my view it's a flaw in the design of the plugin system that the server's pseudoclient UI doesn't have its own list of Installed Client Plugins, since in almost every other respect it's just like a local instance of SageTV Client.

However I believe it should be possible to disable the SageTV service and configure your plugin through the plugin manager UI while running in non-service mode. Then when you restart the service, the UI should inherit the plugin's settings from Sage.properties (assuming those properties don't yet exist in SageClient.properties). But I haven't actually tried it to verify this.