6.4.8 Broken "new API(uiContext)"?

[Fonceur]

Not sure if something changed and it broke the gkusnick's studio tools part or the API(uiContext) itself is broken, but basically now it always return the "SAGETV_PROCESS_LOCAL_UI" version, i.e. you only get access to the server, not the clients or extenders.

In other words, it's no longer possible to use Nielm's web server (unless he's using a different method), SageCQC or SageTCPServer to control a client/extender, or get information about the current media, instead all those calls will be going to (or about) the SageTV server...

Or is anyone still able to control an HD extender from one of those?

[GKusnick]

Did you recently switch to running Sage in service mode? In this mode the server's pseudo-client has access only to its own local UI context; all other contexts (extenders, placeshifters, etc) live in the service process. You need to load your code into that process in order to have access to those contexts.

[Fonceur]

Originally Posted by GKusnick

Did you recently switch to running Sage in service mode?

It happens in both situations. And actually, in service mode you wouldn't even have access to the SageTV Server UI, while the problem here is that you always get access to it...

[GKusnick]

I'm not understanding your issue then. When I call GetUIContextNames() from a Placeshifter client, I get the contexts for all connected clients. When I call it from the server's pseudo-client, I get SAGETV_PROCESS_LOCAL_UI and nothing else, as expected.

Maybe you could provide a bit more detail on how to repro your issue, such as where you're calling it from and how you're getting the context to pass in.

[Fonceur]

Originally Posted by GKusnick

Maybe you could provide a bit more detail on how to repro your issue, such as where you're calling it from and how you're getting the context to pass in.

public SageServer(String uiContext, int portNum) 
{
  API sageApi = uiContext.equals("local") ? Api.apiLocalUI : new API(uiContext);
  MediaPlayerAPI sageApiMediaPlayer = new MediaPlayerAPI(sageApi);
 (...)
}

so basically in 6.3.10, by using SageServer("local", 9250) you get access to the SageTV Server controls, while using SageServer(MacID, 9251), you control the client or extender which corresponds to the MacID. That's how the SageCQC driver works.

Now in 6.4.8, both will only allow control the Server... Which leads me to believe that the problem is with the "new API(uiContext)" part... I guess it could be MediaPlayerAPI(sageApi) that is broken, but then other commands like maximizing the screen which are based on sageApi.global are also going to the server, regardless...

[GKusnick]

That still doesn't answer the question of where the MacID comes from. Is it the result of a call to GetUIContextName() or GetUIContextNames()? If not, what steps have you taken to verify that it is in fact a valid context, i.e. that it matches one of the strings returned by GetUIContextNames()?

Just guessing here, but it's possible that the format of the context strings has changed since 6.3. The API makes no guarantees about that. So if you're generating your own context strings directly from MAC addresses, rather than getting them from GetUIContextNames(), then it's up to you to ensure that you're generating them correctly.

[smoothtlk]

Hi Greg,
Fonceur and I worked on this over the weekend. What we find is that we can control what Client (extender or software) with 6.3.10 but cannot with same settings latest beta. Do you know if the API changed syntax with latest beta? Possibly it's not a "bug" but a not understood change of syntax?

[Fonceur]

Originally Posted by GKusnick

That still doesn't answer the question of where the MacID comes from.

It's the value shown by a router or "ipconfig /all" (i.e. 00085a12b34c for an extender, as shown by the MiniUI loading message or the extender's .properties file). Though I guess there might be a different translation somewhere now...

[GKusnick]

But again, the SageTV API does not guarantee that MAC addresses can be passed in as context names. It so happens that the context strings returned by GetUIContextNames() are derived from MAC addresses in the current implementation, but there's no guarantee that will always be true. The only guarantee is that GetUIContextNames() will return an array of the currently valid contexts, and that passing one of those strings back in as a UI context will let you control the corresponding client. By generating your own context strings out of whole cloth, you're depending on an implementation detail that is not part of the API contract, and so are vulnerable to breakage if the details of the implementation change.

My advice would be to take a look at the results of a call to GetUIContextNames() to make sure you're getting it right. When in doubt, print it out.

Also note that it's possible to specify a made-up MAC address on the Placeshifter command line. This allows you to run more than one instance of Placeshifter on the same client machine (assuming you have enough licenses, of course). But it also means that the MAC numbers you get from ipconfig don't tell the whole story about connected clients and their UI contexts.

[Fonceur]

Hmm, time to play with GetUIContextNames(), it might not be such a bad idea to discover them that way, rather than ask the user to do the work...

[Fonceur]

Originally Posted by Fonceur

Hmm, time to play with GetUIContextNames(), it might not be such a bad idea to discover them that way, rather than ask the user to do the work...

It turns out that it won't work, since the extenders and such won't be loaded before the .jar is done initializing.

OTOH, it seems that nothing is broken. The uiContext simply had to be forced to lower cases, as the upper cases from pasting the text from the filename client\00085A12B34C.properties was a bad idea... As for controlling a SageTV client from another PC, it requires the .jars files and sageclient.properties modifications on that PC, rather than how extenders work... So nothing to see, move along...