MVP service causing PC stutter

[AOSandman]

Now I'm just going to search the forums until I figure out how to have a different skin for the MVP versus the PC.

Here's what I did, quick & simple. Make a copy of the existing "Blue" skin (I called mine "Blue MVP"). Leave the setting on in the original, turn it off in the copy. Now in the Config program, go to the Playback tab & set "MVP Skin" to Blue MVP (or whatever you called yours). The skin that you choose there will only be used on MVPs, not on the PC.

[sub]

I suspect even if he did that, he'd have to avoid using the MVP at the same time as the PC.

[wtg]

Obviously it is a bit too much for the machine, though I don't seem to have any trouble watching a movie on the PC while the MVP is served another. It appears just the menu features on the MVP put the hurt on the PC.

I did a little more experimenting tonight and found my PC's CPU spikes just pressing buttons and navigating the menus on the MVP. That seems odd to me but maybe that's just because I don't know what all it takes to serve a menu to the thing and process it's input. For that matter, I don't know whether it's the Hauppauge code or gbpvr's code that's putting the hurt on the machine, though I suppose I could re-enable the Hauppauge functions and test the vanilla stuff.

Whatever the case, disabling the Next Recording panel is pretty satisfactory until I get around to putting a new motherboard in my machine. The MVP features are still nice and now won't be much of a problem.

Thanks,
Tim

[sub]

For that matter, I don't know whether it's the Hauppauge code or gbpvr's code that's putting the hurt on the machine, though I suppose I could re-enable the Hauppauge functions and test the vanilla stuff.

Its most likely GB-PVR's code.

GB-PVR uses GDI+ for all the graphics, which is reknowned for being a hog. You dont notice it with fast machines, but on a slower machine it can cause a few problems. The are lots more optimal graphics technologies we could have used, but I started GB-PVR as a project to learn C# and .net, and using GDI+ was all part of that. I've often wished I'd used something else, but didnt know at the time. Hindsight is 20/20 and all that.

On top of the normal activity required to generate a screen, before sending it to the MVP each pixel of the image is converted from RGB to YUY2, the image is then zipped for sending across the network. This adds quite a bit of processing.

[wtg]

Ah, well then that explains it. Well, perhaps when you get bored someday you can see if it's possible to drop a couple more yields in the code to make it a bit more multi-tasking friendly. (LOL... it's high on the list, I'm sure. ) It's pretty impressive the brief CPU required to manage the screen.

Thanks again for your help. I don't know what's more impressive... gbpvr and the time you spend on it, or the time you spend supporting it.

Tim

[jksmurf]

Let me know if it corrects you problem. If it does seem to be the source, I'll see if I can find a fix. I'm surprised though, its doing very little when it updates the now/next. I'll also try it here.

Sub did you get a chance (among your 1000 other tasks) to see if there was any scope to fix this CPU usage spike from the next recording widget? My PC is about exact spec as wtg, 1.2GHz celeron, runs fine on MVP bit jerky on PC.

Also, AOSandman originally noted to change this in the special element panel "Nextrecording.xml" (in \skin\blue\panels\ but the "visible="true" line appears to have moved to \skin\blue\Main menu. OK to adjust it there?

k.

[sub]

Sub did you get a chance (among your 1000 other tasks) to see if there was any scope to fix this CPU usage spike from the next recording widget? My PC is about exact spec as wtg, 1.2GHz celeron, runs fine on MVP bit jerky on PC.

I did look, but I cant see any further optimisations I can do on this specific logic. GDI+ is just a little too CPU hungry for these slow machines.

Also, AOSandman originally noted to change this in the special element panel "Nextrecording.xml" (in \skin\blue\panels\ but the "visible="true" line appears to have moved to \skin\blue\Main menu. OK to adjust it there?

It was always in the main menu\skin.xml.

[dottore]

I did look, but I cant see any further optimisations I can do on this specific logic. GDI+ is just a little too CPU hungry for these slow machines.

......and a switch to directx won't do the trick? i mean, would a switch be possible or is it too much work? what about .net 2.0? the same thing there?

i read about it, it has nice features, like an auto-updating installer and so on.... (didn't you have problems with the installer ?).

just an idea....i assume, it's no high priority topic...

[sub]

......and a switch to directx won't do the trick? i mean, would a switch be possible or is it too much work?

We'll never be switching away from GDI+. We just have too much code. It'd be way too much work.

Slow machines just arnt a priority. They werent when I started this project, and they still arent.

[jksmurf]

Slow machines just arnt a priority. They werent when I started this project, and they still arent.

No worries. Good excuse for a new PC. Actually the thing is fine on the MVP, which I use 99% anyway :-) and almost fine on the PC. Ta!

k.