Determining if SageClient is running on Server in service mode

[tmiranda]

How can I differentiate between a SageClient running remotely and a SageClient that is actually running on the server (when SageTV is running as a service)?

Maybe I'm doing something wrong, but I found some rather odd behavior with using GetProperty() in a Plugin implementation class. If you use GetProperty() in the Plugin code, and the code is invoked from a SageClient running on the server when SageTV is in service mode, GetProperty() returns the property from the sage.properties file and not the sageclient.properties file. Invoking the same code from a "real" SageClient (running on the network someplace) GetProperty() returns the value from the sageclient.properties file.

I realize this is probably because the implementation class can only have one instance on the server, but it's still a little odd IMHO and certainly confuses things a bit.

What I am doing is setting a property (using SetProperty()) in the STV code and then trying to retrieve it from the Plugin implementation class.

[tmiranda]

After re-reading the docs I think IsClient() && IsServerUI() is what I am looking for. More testing needed.....

[GKusnick]

Java plugins installed on the server run by default in the service process, not the UI process. If you intend for it to run in the UI process, tag it Desktop in the manifest. (However this may cause installation problems on Linux, where there is no Desktop client.)

[jphipps]

I am currently using the following to determine if it is a client:

Global.GetUIContextName().equalsIgnoreCase("SAGETV_PROCESS_LOCAL_UI") || Global.IsClient() || Global.IsServerUI() || Global.IsDesktopUI()

For some strange reason, i have found that on a client, the IsClient() seems to work, but for a client running on a server, all the calls seem to return null, but the GetUIContextName() does return the "SAGETV_PROCESS_LOCAL_UI" value, which is usually only a client, since placeshifters and extenders return the MAC address...

Thanks,
Jeff

PS. Sorry I hadn't responded to your email.. been tied up with work problems...

[tmiranda]

Originally Posted by GKusnick

Java plugins installed on the server run by default in the service process, not the UI process.

I figured that part out. The issue I am having is that from a Plugin I need to retrieve a property that I want set on a per-UI basis. I can't simply call GetProperty() from the Plugin because it fails under one condition, when the SageClient is running on the server and SageTV is running in service mode.

Normally when GetProperty() is called in the Plugin from a placeshifter, or extender (or a SageClient not running on the server) it retrieves the property from the appropriate "client" property file. In the one case I mention above when SetProperty() is called from the STV it puts the property in the SageClient.properties file and the Plugin retrieves properties from the Sage.properties file.

I think the solution is to detect the special case in the STV and then make sure I put all of the properties for that special case in the server properties file.

[GKusnick]

Originally Posted by tmiranda

I think the solution is to detect the special case in the STV and then make sure I put all of the properties for that special case in the server properties file.

This seems like a bad solution to me. Client properties belong in the client-specific properties file, where Get/SetProperty puts them. If your Java plugin is not accessing the correct file, then your solution is either to make sure it runs in the UI process (using the Desktop tag as I mentioned earlier), or if it must run in the service process for some other reason, then use the appropriate client UI context when making your Get/SetProperty calls.

[JREkiwi]

I've been using

sagex.api.Configuration.GetProperty(sagex.SageAPI.getUIContext(), "blah/blah", true)

which is working for me.

John

[tmiranda]

Originally Posted by GKusnick

This seems like a bad solution to me. Client properties belong in the client-specific properties file, where Get/SetProperty puts them. If your Java plugin is not accessing the correct file, then your solution is either to make sure it runs in the UI process (using the Desktop tag as I mentioned earlier), or if it must run in the service process for some other reason, then use the appropriate client UI context when making your Get/SetProperty calls.

Yup, it's an ugly solution. I (think) I can't make the "java Plugin" run in the UI process, because the java code is running as a "General" Plugin. The physical call to GetProperty() is in the Plugin.getConfigSettings() method. (I want to display different settings depending on a property that is set on a per-UI basis.)

Another solution is to create my own settings dialog and forget about using the Sage Plugin Config options. That's probably the cleanest thing to do.

[GKusnick]

Originally Posted by tmiranda

I (think) I can't make the "java Plugin" run in the UI process, because the java code is running as a "General" Plugin.

A General plugin (i.e. one with a Java ImplementationClass) can run in the UI process. That's what the Desktop tag in the manifest is for. My Studio Tools plugin is an example of this.

Originally Posted by tmiranda

Another solution is to create my own settings dialog and forget about using the Sage Plugin Config options. That's probably the cleanest thing to do.

If the only purpose of your General plugin is to provide a config screen for your STVI (aka "UI mod") plugin, then you might want to take a look at my STVI Configurator, which allows you to write plugin config methods in Studio code rather than Java, and still use the built-in plugin config machinery instead of having to roll your own config dialog.

[tmiranda]

Originally Posted by GKusnick

A General plugin (i.e. one with a Java ImplementationClass) can run in the UI process. That's what the Desktop tag in the manifest is for. My Studio Tools plugin is an example of this.

I didn't realize that's what the tag did, thanks for the information.

If the only purpose of your General plugin is to provide a config screen for your STVI (aka "UI mod") plugin, then you might want to take a look at my STVI Configurator, which allows you to write plugin config methods in Studio code rather than Java, and still use the built-in plugin config machinery instead of having to roll your own config dialog.

The implementation class does a lot more, but I still need to learn how to use your STVI Configurator.

I moved the config options to a new dialog and I think that is actually the best way to go. It provides more uniformity with the other dialogs and cuts down on complexity.

As always, thanks for your help and insight. I'm glad you take the time to help newbies.

[Opus4]

Originally Posted by tmiranda

How can I differentiate between a SageClient running remotely and a SageClient that is actually running on the server (when SageTV is running as a service)?

BTW: you can determine if the UI is a server UI being used with the service using the same method that the System Information menu does:

If !IsClient() && !IsRemoteUI()
|--InfoText = "Service Mode: " + If(GetProperty("client","")=="true", "Enabled", "Disabled")

That is for an installation of SageTV (server); if it is an installation of SageTVClient that is also running on the server, then I think IsClient() will be true anyway.

- Andy

[stuckless]

Originally Posted by tmiranda

Another solution is to create my own settings dialog and forget about using the Sage Plugin Config options. That's probably the cleanest thing to do.

This may be off base, but the PluginAPI doesn't care where you store your settings. ie, GetProperty/SetProperty is just one implementation that you might choose to do. So, you can choose to use any other means, ie, UserRecord, database, etc to store your actual configuration.

If you are extending the sagex AbstractPlugin and using the addProperty() methods to build up your configuration, then can you can assign your own persistence to each each property as well, by setting a custom IPropertyPersitence implementation. (you can also set a visiblility handler and a validation handler)

So, if you build your panel, then you'll probably still need to solve where you store configuration,etc.

If you haven't looked at the AbstractPlugin in sagex, it's worth checking it out. It allows you to easily build up your configuration, use alternate persistence models, and easily handle onchange events (or register yourself as a listener to other events) using annotations. Here's the AbstractPlugin, and here's a couple of implementations to see how it's used; Sagex Service Plugin; Phoenix Metadata Plugin.

Bottom line, I don't think you need a custom ui panel, you can probably do what you need using the existing plugin configuration panels.

[tmiranda]

Thanks for the help.