Help me to understand MVP rendering

[dflachbart]

Hi,

since yesterday I am proud owner of my first MVP

After setting it up last night everthing seems to work fine, but I noticed one thing: it takes about 8-10 seconds for the Guide to come up, and during this time the playback on the server is stuttering like crazy ...

It has to be certain code in the current version of the SageMC STV which is responsible for this, since an older version does not exhibit this behavior. I will of course try to track down the changes on the widget level in the STV, but maybe someone could explain to me in more detail how this MVP stuff works in general.

So far I understood that the MVP hardware is used to render the STV. So what gets actually sent over the wire to the MVP, some intermediate widget representation ? And what about the STV code logic, does this still gets executed on the server ? Any ideas what kind of code could be causing such a huge delay and workload on the server ? I am using the same STV version on client as well as placeshifter on my LAN, and did not experience this problem there...

Thanks,
Dirk

[nielm]

Think of it like controlling sage via a VNC client (which it knd of is) everything 'runs' on the server, the GUI rendering is done on the server, then the rendered image is sent over the network to the MVP using VNC's remote frame buffer protocol (google:MVP+VNC+RFB)
(Note: MPEG2 decoding and playback is done separately and natively by the MVP)

Anything slow/complex (such as an extensive search and program guide rendering) could be slowing down your server, but it would also slow down the server when you perform the same actions on the server's sage GUI...

[dflachbart]

Originally Posted by nielm

everything 'runs' on the server, the GUI rendering is done on the server, then the rendered image is sent over the network to the MVP using VNC's remote frame buffer protocol

Ah ok, so my assumption that any GUI rendering is done on the MVP itself was wrong ... Then it's even more strange, since I dont have any problems whatsoever on server, client, or placeshifter

Could it be that simply too many frames (caused by some widget code) are rendered on the server, and that this could cause the problems ?

And thanks for the explanation, I will have a look at the links ...

Dirk

[amg]

Originally Posted by nielm

Think of it like controlling sage via a VNC client (which it knd of is) everything 'runs' on the server, the GUI rendering is done on the server, then the rendered image is sent over the network to the MVP using VNC's remote frame buffer protocol

I thought this was true in the past as with Matt's MVP plugin and the Hauppauge MVP software, but I thought Sage's MVP implementation was to have the MVP render the screens itself.

[BobPhoenix]

Originally Posted by amg

I thought this was true in the past as with Matt's MVP plugin and the Hauppauge MVP software, but I thought Sage's MVP implementation was to have the MVP render the screens itself.

I agree. According to this post the GUI is rendered on the MVP.

BobP.

[Opus4]

This may change the meaning of what I posted before: yes, the MVP renders its own UI, just like any other client that draws a UI. But, the MVP (& Placeshifter, therefore) do not run the STV code directly. All data manipulation/STV code is executed on the server, which then tells the MVP how to render its UI. This is pretty much the same as for any UI, even for the local one you see on the server itself.

While this is faster than having the server draw the latest menu & send it as an image to the MVP for display, it isn't as fast as being on a local PC, since it has to go over the network/etc. If you have lots of animations going on, the MVP won't handle that as well as the PC UI, so that could cause a slowdown.

Also, if you have very extensive data manipulations going on, that could use more cpu time on the server. This shouldn't be affecting the server's own playback, but I don't know what all you might have going on, either directly in the STV or via some added cusotm java library or such.

Essentially, since you said an older version of SageMC didn't have the same issue, tracking down that difference is probably the best course, as you said.

- Andy

[rickw]

Originally Posted by flachbar

After setting it up last night everthing seems to work fine, but I noticed one thing: it takes about 8-10 seconds for the Guide to come up, and during this time the playback on the server is stuttering like crazy ...

I had experienced the same behaviour with my MVP and using your updates to the SageMC. I'd assumed it was related to extra work the guide code was going through to change the color of the cells and/or place icons on the guide.

Going back to the 5_10 release of SageMC eliminated the problems. (Also returned the WAF back to normal)

[dflachbart]

Originally Posted by rickw

I had experienced the same behaviour with my MVP and using your updates to the SageMC. I'd assumed it was related to extra work the guide code was going through to change the color of the cells and/or place icons on the guide.

Going back to the 5_10 release of SageMC eliminated the problems. (Also returned the WAF back to normal)

Ok, I finally figured it out. I spent the last two hours debugging, modifying the STV, trying this and that, but to make a long story short, it was something entirely different:

after I switched the MVP off (I hadnt since I installed it) and on again, everything is fine ...

Doh ...

Don't know why, but this did the trick (maybe properties got only set in the server executing after the first shutdown...?). The guide is now as responsive as it is in 5_10 (even with all icons turned on), and the server doesn't stutter any more. All in all it is a little slower than on the client, but still very usable.

So dunno if this was a different problem than the one you encountered, but if you didn't shut off the MVP after trying the new STV than I would certainly give this another try.

Dirk