Service mode vs client in v7

[Fonceur]

I am trying to get SageTCPServer to be configurable within the plugin interface... Currently, one instance is loaded from sage.properties (to pull the list of recordings and so on, or to control extenders) and another is loaded on any software client, like the server's UI, in order to control it (UI navigation, playback, etc.). Each instances monitors different TCP ports for communication with other pieces of software.

While I guess a software client on a different PC might be able to install a local copy of a plugin and configure it... What happens with the server's UI, since that's also where you would configure the service mode plugins...

My guess is that I should also submit an identical copy as SageTCPServer-client and set it as Desktop only, but maybe that's overkill...

[gplasky]

You might want to take a look at shadeblue's info popup/caller ID plugin. There is a InfoPopup/CaleerID plugin in General that is installed on the server. I can see it as an installed plugin from a client PC and I can configure it from there. He also has the InfoPopup STVI in the UI Mod that needs to be installed on any PC client you want the popup to show up. Maybe look at doing it similar to that?

Gerry

[Fonceur]

Originally Posted by gplasky

You might want to take a look at shadeblue's info popup/caller ID plugin.

Thanks, indeed that's the same kind of issues he had moving to the SageTVPlugin interface. So I am looking through his thread.

[GKusnick]

Why do you need to install anything on the client? Code running on the server can invoke API methods on any client using the appropriate UI context. This includes using SageCommand() calls to navigate the UI. (This is how the web server's remote control feature works, for instance.) So all you should need is to install one instance of your plugin on the server and have it instantiate an internal class for each client it wants to control. You should then be able to configure them all from one screen.

[Fonceur]

Originally Posted by GKusnick

Why do you need to install anything on the client?

Based on the info/popup thread, indeed I don't anymore. Though I'm not sure that when the original project (SageCQC by Beelzerob) was started 4 years ago, it would have been the case.

Code running on the server can invoke API methods on any client using the appropriate UI context.

Right, but I don't know how easy that was to do before the GetConnectedClients() of SageTV 7.

[Fonceur]

Originally Posted by GKusnick

Code running on the server can invoke API methods on any client using the appropriate UI context.

I'm trying to get the list of context with your library, but it's not working, any ideas? This is in service mode with the server's UI that should appear in the ConnectedClients...

Global SageGlobalApi = new Global(API.apiLocalUI);
String[] listOfContextNames = SageGlobalApi.GetUIContextNames();
String[] listOfExternalContextNames = SageGlobalApi.GetConnectedClients();

Both lists are empty... I've tried variations like API.apiLocalUI.global.GetUIContextNames() or using API.apiNullUI, but I still didn't get anything.

[GKusnick]

It's a bit weird to be using apiLocalUI in service mode, since there is no local UI in that mode. I would use apiNullUI in that case.

Also you don't need to instantiate the Global class yourself. Every instance of API already has an instance of Global. So apiNullUI.global.GetUIContextNames() would be the intended way of accessing it.

All of that said, however, I'm not seeing any obvious reason why your code shouldn't work. The only time both lists would be empty is when the service first boots up, before any clients or extenders have connected (or after they've all disconnected). Have you checked the logs for exceptions?

[Fonceur]

Originally Posted by GKusnick

It's a bit weird to be using apiLocalUI in service mode, since there is no local UI in that mode. I would use apiNullUI in that case.

Right, that's why I tried both. One of these days I'll clean up the source code from all the initial guess work that went in...

Also you don't need to instantiate the Global class yourself. Every instance of API already has an instance of Global. So apiNullUI.global.GetUIContextNames() would be the intended way of accessing it.

OK, I tried either but had the same effect anyway.

The only time both lists would be empty is when the service first boots up, before any clients or extenders have connected (or after they've all disconnected).

That's most likely the problem. I was hoping to pre-configure my plugin on launch, but it makes sense that there are no context available yet (and that would be why I had left a comment in my code about the clients possibly not being connected then). I am doing it in the Start(), but I likely need to delay it even further than that. The proper way would probably be to use a listener for ClientConnected and add any unknown ones.

Have you checked the logs for exceptions?

Yes, those were some clean empty String[], no null, exceptions or anything.

[Fonceur]

OK, so from the getConfigSettings I do find the server's UI context through GetConnectedClients(). The bad news is that it uses a different local port each time the SageTV service is restarted, so I won't be able to use it on the next relaunch...

[GKusnick]

Right, you have to strip off the port before saving it away, and then match it back up by IP next time it reconnects.

In fact you probably want to translate the IP to a host name and match by that instead of by IP, in order to be invariant across DHCP lease reassignments.

For extender and Placeshifter clients, the MAC address is probably the appropriate invariant to use. (You can have more than one Placeshifter connection from the same host/IP, so long as they have different MAC addresses.)

[Fuzzy]

I'm really hoping that at some point in the future of SageTV, the Client/Server model gets reworked a bit to avoid some of these hassles. There's really no reason for keeping the extenders/placeshifters IN the server process. Things would end up being much smoother if the server ONLY ever did recording/serving, and ALL clients connected to it via a standardized protocol. Even if extenders/placeshifter's still ran on the server hardware, it would be MUCH easier if the server launched a new JVM with that handled that particular connection, and it communicated with the server process via the same IP protocol that the full clients do. Then, you'd have no reason for these UI hosts to even be ON the server.