Choppy Playback on Main PC When MVP Server is running

[cgmt]

My main pc is connected to a TV and then the MVP is connected to another TV. When the MVP server is running, the playback on the Main PC is choppy. About every 5-6 seconds it seems to skip for the lack ofa better term. The main PC is 3 Ghz with 1GB or RAM so it should have plenty of horsepower. Everythign through the MVP on the other PC is great. The PC that runs the MVP service, should it not be used to watch tv on? It works great when the MVP service is not running, so I was wondering how I can solve this problem. Attached are the logs. Anyone have any ideas?

[HtV]

It's not completely clear to me: how many pc's, mvp's have you got and how are they all connected? Wireless or wired etc etc.

[cgmt]

Sorry about the confusion. I have one PC with dual PVR-150's, 1GB RAM and 3GHZ processor that is connected to my PC and Wired(100 MB) to my LAN.

Then upstairs I have a Wireless MVP connected wirelessly to my 802.11G LAN. Everything on my MVP is working greeat(besides some of my AVI's, but that is another issue), and the choppyness is on the PC connected to the PC. There are a few config setting that I am curious about. I have not changed aything yet but I was wondering if someone could explain these settings and what they do

UseFFDSHOW - Does this mean it will use FFDHOW for all encoding and decoding in GBPVR?

MvpHighPriority - I under stand what the setting does, but I was wondering if anyone had any sugestions for my environment.

MVPTranscodeUsingFFmpeg and MVPTranscodeUseFFDSHOW and can they be used together or jsut seperately?

Thanks in advance for any assistance..

[cgmt]

I have read through the docs on the WIKI for the MVP, but the issue is not with the MVP, it plays great(I still have a few issues with certain AVI maily my h264 encoded avis's) but that is another issue. My issue in the main GBPVR server has the choppy TV NOT the MVP. Any ideas?

[wtg]

I had this exact same problem. I run 3 MVPs and the more I had running, the worse it was.

AOSandman helped me solve the problem and sub explained why it happens. MVP Service causing PC stutter Basically the Next Recording widget is the culprit. In the Blue Skin it's on the main menu screen and it updates itself every 5 seconds, requiring a redraw of the MVP screens. The GDI+ process of rendering the screen, compressing it and transmitting it puts quite a hit on even a beefy PC, if only briefly, and this is what's likely the source of your hiccups. I originally encountered the problem using a 1.1 GHz Celeron but even with my 2500+ AMD it's noticable.

The Next Recording widget is easy to disable. In your MVP skin's directory open the Main Menu folder and the file skin.xml. Almost at the bottom you'll see the Next Recording panel code and simply set it's Visible attribute to False instead of True. In only wanted to do this for the MVPs so I took AOSandman's advice and copied the entire blue skin folder to another name (called mine Blue MVP), turned the Next Recording panel off and configured the MVPs to use the new skin in the Config app.

The Clock widget forces an update on the MVP screens everytime it changes as well, if only once a minute. You might want to disable it too, and it's found in the same spot as the Next Recording widget.

Hope this helps,
Tim

[cgmt]

Thanks wtg and tipstir for the tips, it really helped out is is running great now. I disabled those settings in the skin and then used the copy for the MVP and kept them enabled for the main PC. I also used that tool to make the reg settings and everything is runnign great now.

In regards to H264 encoded avi's, do you have any tips to be able to watch them through the MVP? I am not trying to use FFDShow for the MVP decoding. Is that the recomended approach? I have read alot of posts on avi usage but I have not got it workiing great yet. Any tips on AVI usage on the MVP would be helpful.

Thanks

Chuck

[wtg]

I had trouble when the use of FFMpeg was first added for real-time AVI transcoding to the MVP. Someone mentioned lowering the bitrate from 2400 to 2000 in config.xml and that made all the difference:

  <MVPFFmpegTranscodeCmdLineNTSC>-y -i "{SOURCE_FILE}" -b 2000 -ac 2 -ab 128 -r 29.97 -s 352x240 -f svcd "{DEST_FILE}"</MVPFFmpegTranscodeCmdLineNTSC>

I'm not really sure why this was necessary because it appeared that my CPU was able to keep up at 2400, but whatever... it worked. I also bumped up the MVP pre-delay just a bit.

[4zm4r3d02]

By chance do you have L2 Cache enable in Windows XP? Most likely it's disable.

According to http://mywebpages.comcast.net/SupportCD/XPMyths.html , this setting has no effect on modern machines, and can in fact slightly reduce performance in some cases.

There are lots of other interesting tweaking myths explained on that page.

[HtV]

Did you read the article at all?
According to the article the l2-cache is enabled by xp automaticly.

[HtV]

I know that L2 Cache is enable by default but not for the true size you might have on your CPU more like 256KB or less, You would have to change it. I've mentioned this before somewhere on forums.gbpvr.com

Ok, I suggest you read it at home then .

Source one: http://support.microsoft.com/kb/183063 :

SecondLevelDataCache records the size of the processor cache, also known as the secondary or L2 cache. If the value of this entry is 0, the system attempts to retrieve the L2 cache size from the Hardware Abstraction Layer (HAL) for the platform. If it fails, it uses a default L2 cache size of 256 KB. If the value of this entry is not 0, it uses this value as the L2 cache size. This entry is designed as a secondary source of cache size information for computers on which the HAL cannot detect the L2 cache.

This is not related to the hardware; it is only useful for computers with direct-mapped L2 caches. Pentium II and later processors do not have direct- mapped L2 caches. SecondLevelDataCache can increase performance by approximately 2 percent in certain cases for older computers with ample memory (more than 64 MB) by scattering physical pages better in the address space so there are not so many L2 cache collisions. Setting SecondLevelDataCache to 256 KB rather than 2 MB (when the computer has a 2 MB L2 cache) would probably have about a 0.4 percent performance penalty.

Source 2: https://www.microsoft.com/technet/pr....mspx?mfr=true :

Do not change the SecondLevelDataCache entry
Some third-party sources have erroneously reported that modifying the SecondLevelDataCache registry entry in HKEY_LOCAL_MACHINE\System\CurrentControlSet \Control\Session Manager\Memory Management can enhance system performance. The second level (L2) cache is recognized by the operating system and is fully utilized regardless of the setting of this parameter.

cya Hans