Reply to thread

Message: <blockquote data-quote="joboehl" data-source="post: 105050" data-attributes="member: 23490">Hi, I've being doing some testings with the TVServer and plug-in in order to help improving the zapping mechanism. Hope some ideas can popup and maybe help frodo in this area. First, the setup used:Server - Sempron 2600+, 512Mb Ram, 100Mpbs - PVR500 + MCE Blaster. Client - AMD X2 3800, 1Gb Ram, 1Gbps LAN. The testing:I've timed 10 channel changes from the time the user clicked the Channel in the miniguide and the time the first image from the selected channel appeared in the screen. First code. SVN 12640 - Average time: 5.45 seconds. Second code: Custom - Average time: 4.74 seconds.The code changes: What the second codes does differently: The second code have some modifications that force the client to seek a specific position in the stream. This position is retrieved as being the end-of-stream at the server, and not at the client. This kills the local buffer (i've timed it about 3 seconds behind the server stream). So why the second code is not 3 seconds faster than the first code?Well, MPClient code tries not to position the stream at server trough the network because this is very expensive. Since the second code  forces the positioning, it pays the price for doing it. You can add a couple of seconds positioning the stream  trough the network, and that time can vary depending on the network conditions. Initial findings: - Forcing the positioning can help, but not that much and will have it's drawnbacks (zapping speed will depend on network conditions, time can vary and etc). - The great benefit of the test was to show how much the buffer affects the zapping behavior. - Most of the time the user waits at the client is not for the actual channel change, but watching what remains in the buffer (3~4 seconds). The buffer is there for a reason, it helps in case of network bandwidth problems and etc. Some initial ideas:- To have a configurable buffer size (at the client), the user could customize the Plug-in behavior. So dedicated 1Gbps machines could run with very little buffer (close to noting), while Wireless machines could buffer more to avoid problems. Still could not find this buffer so I can't do much testing with it, but will try to. - The same way, the amount of time MPPlug-In waits for doing a SeektoEnd (SeekAbsolute) could be configurable. This way Gbps machines could be less tolerant and use the seekabsolute more often (Ex: any delay greater then 5 seconds) and WLAN could allow for longer delays without repositioning the stream,and those avoiding some freezed screens. BTW- While doing a Seek in the stream the TV image is freezed, that's why some user might want to avoid, specially in slow networks where this image could be freezed by quite sometime. Well, hope I could give some food for thoughts.</blockquote>

Verification