UIContexts, and the MVP?

[beelzerob]

Never underestimate how much beelzerob does not know....

Here I think is my fundamental lack of understanding:

Is the UI context kind of like a hook, that you can use to control things? I guess here's what I'm expecting....that somehow, I'll get an MVP_UI_CONTEXT....and that I can then use gkusnick's API class to create a new API based on that context...and then, all of the control I'm now exerting over Sage (play, watch files, get status info, get show info....) will now extend to the MVP also. So for me, the UI context is like an address location to the MVP.

Do I understand that at all?

Otherwise, I'm not exactly sure what the "placeshifter client" is. All I have is...... sage. Is the placeshifter client something different? That's a separate purchase, isn't it? Isn't the idea that you purchase a sage client, you install it on a different PC, and then you can watch shows on that PC just like you can on the server? I'm asking because I've only ever used just the server for everything...I setup recordings on it, I watch my recordings on it, etc. The only time I've watched videos on other PC's was just by double-clicking the video file over my network, which brings it up in WMP.

Let me give a little background to what my code does right now.....currently it's hardcoded to use the LOCAL_UI. I believe IVB has been using it on a sage client, and it works great. Correct me if I'm wrong....but basically, the local ui context means it'll control what it is currently running on, right? Which is why it works if you run the code on the server (it'll control the server), and it works if you run the code on a client (it'll control the client)....but you can't control the client from the server or the MVP from the server because that's a different context, not the local one.

Thanks for the patient explanation. I'm sure if I had a more elaborate sage setup, this would make more sense to me.

[GKusnick]

Yes, the UI context is kind of like an address. But don't think of it as a network address that's used to forward commands to the remote device, because that's not how it works. It's more like having multiple monitors connected to one PC, with a Sage window on each monitor. To do something to a particular window, you'd need a window handle of some sort to say which one, and that's what the UI context provides. It's just that with the MVP, the second monitor is in another room, connected by Ethernet instead of DVI. But all the UI computation still happens on the server PC.

You can think of Placeshifter as a sort of software MVP that runs on a PC. Like the MVP, all the UI computation happens on the server, and only the actual window rendering is forwarded to the remote PC. (This is different from SageTVClient, which runs the entire UI locally.) Remember you can use Placeshifter free for 15 days, so you might want to download it and give it a try to get some hands-on experience with what you're trying to support.

[nielm]

beelzerob:

Download the placeshifter trial from Sage's web site.
Install it on a computer in your LAN (the Sage server if necessary)
Disable Service mode on the Sage server (if you are using it) and restart the server
Enable the Placeshfter server options on your Sage server.
Run the placeshifter, and connect it to your server.

Now, startup studio and enter:
java_util_Arrays_asList(GetUIContextNames()) in the tools/expression evaluator -- this will now list 2 contexts: the local and the placeshifter (the asList function converts a non-printable String[] into a printable List of Strings.)

You can now play with your CQC driver and try to get it to query and control both UI contexts...

If you feel like having some fun (!) try remote controlling each UI context by calling the Java API from the Studio expression evaluator:

Send TV command to first UI context:
sage_SageTV_apiUI(GetElement(GetUIContextNames(),0),"SageCommand",java_util_List_toArray(DataUnion("TV")))

Send TV command to second UI context:
sage_SageTV_apiUI(GetElement(GetUIContextNames(),1),"SageCommand",java_util_List_toArray(DataUnion("TV")))

[beelzerob]

Hehe...I like your idea of fun.

Ok then, if I do all that....then you're saying that it's pretty much the exact same process if it were an MVP instead of the placeshifter client?

[nielm]

yep -- they both run 'in' the server process using separate UI Contexts..

[beelzerob]

Ok, success of sorts.

Installed Sage placeshifter on a separate PC, and then checked the UI contexts:

Found 2 UI Contexts:
UI Context 0: 00e04cdc....
UI Context 1: SAGETV_PROCESS_LOCAL_UI

Found 0 connected clients.

Ok, so just having the sage placeshifter up and running (without having anything streaming to it or playing on it), I saw the separate context for the placeshifter (I think that's its MAC address). And I can use that actual MAC string as the UI context for the API?

Now the question remains....when IVB does the exact same thing I did above, but with the MVP instead....why don't I see a 2nd context?

[Opus4]

Originally Posted by beelzerob

Ok, so just having the sage placeshifter up and running (without having anything streaming to it or playing on it), I saw the separate context for the placeshifter (I think that's its MAC address). And I can use that actual MAC string as the UI context for the API?

Yes, the UI context you get this way is the same thing used to specify which one you want to affect, as mentioned towards the bottom of this page.

Now the question remains....when IVB does the exact same thing I did above, but with the MVP instead....why don't I see a 2nd context?

Is this code running as part of the service? If so, the service has no UI, so there is no local UI to report & you will only see the context for the MVP that he has connected.

- Andy

[beelzerob]

The code is java run using the loadable_at_startup thing, so I believe that's what you mean, yes, it is running as part of the service.

From what I recall, last time he did this, though, I DID see the local UI, but not a MAC address kind of UI.

IVB, see if you can run that test again with the code, in the same manner that I just did that test, and send me the sage log, we'll see what it's got.

[IVB]

sorry, what manner is that? The last log had a show actually playing on the MVP when I took it, is that what you mean?

[beelzerob]

Well, here was my configuration:

PC1: SageTV server (main install).
PC2: Sage Placeshifter (so, this is your MVP)

Put the sagecqc.jar load statement into the sage.properties file for the sage TV server (so, not a client). Then, on the MVP, just have it showing some Sage interface screen (it doesn't need to be running a show...I think I understand now that the server actually renders the UI screens themselves and passes them on to the MVP). Then, once all that has taken place, connect with the CQC driver, then disconnect/stop everything and send me the logfile. I realize you may have already done all this, but let's try again...maybe it'll work this time.

[IVB]

ok, sent off. Tried it 2ways:
1) load_at_start class in the sage.properties file
2) load_at_start class in the sageclient.properties file

both times on the server.

[beelzerob]

Ok, to my understanding, we definitely don't need the sageclient.properties one. You need to run the runnable from the server, not a client.

[beelzerob]

Thanks all for your help! It has turned successful. I finally found the MAC address, plugged that in, and away it went! Now, it's about time to re-write my java code completely so that it's versatile enough to handle being a server or client instead of having to be hardcoded with the UI context.

Thanks again! (and lots more questions to come, but in their pertinent threads)

[beelzerob]

Now that I've learned how to get the correct context, my next step is to make efficient use of them.

What I'd plan to do is simply create an instance of my server code for each UI context in use. But in order for them to operate independantly, I'll need to have them exist/run in their own thread.

Do regular java Thread() calls and classes work with this Sage stuff? I noticed the Fork() command in the API, but it seemed related to widgets, which I don't think I'm dealing with. I just want to create a new runnable instance and then set it loose in its own thread.

[GKusnick]

You're doing that already. When you put "implements Runnable" in your class header and add it to load_at_startup_runnable_classes, you're telling Sage to start that class in a new thread. Nothing stops you from defining more Runnable classes and launching them in threads of your own, using the regular Java thread machinery (which is all Sage is doing with load_at_startup_runnable_classes).

[beelzerob]

Eeeexcellent.

Ya, I was writing threaded code in java long before I actually learned what that meant! I'm finally programming in java at work, so I'm learning what it is I already kinda knew...it's a relief to understand this stuff more.