Acer Revo Playback

[trummel]

Could someone explain what the difference is in the way a GBPVR PC client handles playback from 'Recordings' and 'Video Library'. If I set the client in question up to look at the same folder for both libraries, the same BBC HD H.264 .ts file plays happily from the Video folder, but stutters severely from the 'Recordings' folder. I've tried setting playback to both streaming and File Share, but it makes no difference.

The client in question is a new Acer Revo R3610 with the Ion 330 GPU. It is using EVR and Windows 7, with the correct codec's (cyberlink) and it plays the .ts files perfectly in PDVD8. The hardware acceleration seems to be working as the cpu load is minimal.

Network bandwith isn't a problem as it's a Gbit lan and the network load on the server is only showing at 20 mb/s. I don't think its a disk bottleneck on the server as 3 NMT's play quite happily together, even whilst the Video Library file is playing.

I've tried installing Hoborg's SAF and it made no difference. I've used graphedit to look at the codec's in use and they appear the same for either source, although I cant get it to report what PDVD8 is using.

Any suggestions where I could start looking for the bottleneck would be gratefully received.

Martyn

[pBS]

try using the mpchc demux...download from mpchc standalone filters the mpeg splitter. register it with regsvr32 MpegSplitter.ax

search config.xml for 'demux' and set it to use "MPC - Mpeg Splitter (Gabest)"

in recordings screen, files are 'pushed' from server and received by client...in vid lib. they are accessed directly from net path..

might also try upping the client read cache size...also in config.xml under client section..

[trummel]

Thanks for the response pBS.

Sorry if this is a dumb question, but should that MPC splitter be on the server or the client?

I have the client read cache (<ClientModeCacheReadSize>) at 65536 as per another thread on here, is it likely to be beneficial to go higher than that?

[pBS]

yea, i went higher with cache and it did show some effect...
i would double it untill it looks good...but use the demux anyways..
and the demux gets installed on client side...server sends the file whole, client splits it and decodes...
the demux won't be used for in=progress recordings/livetv, but it will for everything else..

[trummel]

I have tried the cache up to 262144 but it makes no noticeable difference. I already had the mpc splitter (from SAF), so I made the config.xml change you suggested and restarted pvrx2. Graphedit still says I'm using the Mpeg-2 Splitter I've attached the config.xml and .grf if they can throw any light.

[trummel]

I've just been trying to run my H.264 ts recordings through MPC with the MPC Splitter. It doesn't seem to recognize them, although the Haali splitter does. I tried putting the Haali splitter in as the Demux in config.xml, but gbpvr still insists on using the Mpeg-2 Splitter.

[pBS]

it'll always use the ms splitter for in-progress recordings, can't do anything abou that, but recordings screen stuff should play with the mpc splitter...
mpchc has a splitter built-in so i don't think it'll use the external one, unless you uncheck the internal mpeg splitter...

oh and i set the mpchc splitter merit as high as possible..
that's probably why it didn't use it..
it should be able to play any .ts and even .m2ts like bdroms...
i've yet to come across any file it wouldn't split..

[trummel]

I've been doing some experiments trying to find where the bottleneck is in my systems. Even though 3 NMT's play HD concurrently without issue, the server load imposed by 1 or more of the revo's seems to be what is causing the stuttering in the Revo playback.

As an experiment, I reinstated an older server, with a slower disk and network card. The NMT's continue to work, but the Revo is significantly worse. I am guessing it's something in the way the NMT streams the data through the web port that make it packet the data up more efficiently.

Despite hours spent in perfmon trying to spot the difference in the various network and disk throughputs, I'm no further forward and am rapidly coming to the conclusion that the Revo is simply unsuitable as a GBPVR client.

[sub]

Despite hours spent in perfmon trying to spot the difference in the various network and disk throughputs, I'm no further forward and am rapidly coming to the conclusion that the Revo is simply unsuitable as a GBPVR client.

I think its more that GB-PVR isnt very good at client/server stuff. It hasnt really had any improvements on this front since it was first introduce to do client/server for the analog tuners that were the prevalent at the time. Since then a lot of things have changed, with most people now using digital tuners, and much of those for HD MPEG2 and H.264 etc. It really needs more work before GB-PVR can be considered a decent client/server setup.

[imagn]

I think its more that GB-PVR isnt very good at client/server stuff. It hasnt really had any improvements on this front since it was first introduce to do client/server for the analog tuners that were the prevalent at the time. Since then a lot of things have changed, with most people now using digital tuners, and much of those for HD MPEG2 and H.264 etc. It really needs more work before GB-PVR can be considered a decent client/server setup.

Any chance you might be working on improvements to the client/server, i would certinly appreciate it if you ever have the time