TIP: GBPVR networked client

[A_Brass]

I cant say I ever looked so closely at the nework traffic. I was able to get mine working without changing the quality settings on the "server". But you are correct about the shared drives. a UNC path does not work correctly. When I tried it this way it caused stuttering on the sever. When I moved the recording drive letter to "Z:" and mapped the client to the same drive letter I was able to get it working.

In the config.xml I tried two different things. I replaced localhost with a unc path to the server and also tried a ip. The direct IP worked better.

Example:
\\server\gbpvr\gbpvr.mdb --- didn't work as well as:
\\192.168.1.1\gbpvr\gbpvr.mdb

I'm not sure what the difference is but it worked better with the IP.

[djtaylor]

Example:
\\server\gbpvr\gbpvr.mdb --- didn't work as well as:
\\192.168.1.1\gbpvr\gbpvr.mdb

I'm not sure what the difference is but it worked better with the IP.

The only difference that should make is to avoid the initial traffic required to resolve the hostname to an IP address, all traffic after the name resolution occurs will be IP based anyway.

I can't offer any other explanation, i'm not doing this remote client thing - sorry

David.

[djtaylor]

haven't looked yet but i believe so...any suggestions on a fix?
can i ignore them or filter them out?
i just noticed there were wayyy more than when normally playing a file on the sent side..and then noticed it was 1-for-1 with recieved packets..
[normally only about 10% of recieved]
this is what makes it jumpy...for sure...
any help greatly appreciated..

As per my other post, i'm not doing this remote thing so can't offer much except that if the remote client is pulling the file across the network as a network file as per Windows SMB data, then there will be a TCP session set up and packets will be ACK'd. You can't avoid that, failure to receive an ACK will cause the packet to be retransmitted again so any concept of filtering will just make it worse and in fact nothing will happen because the TCP send window will get full of packets waiting to be acknowledged!

I suspect (though haven't bothered to confirm) that data is sent to the MVP as a UDP data stream and is thus not acknowledged, nor does it need to be.

David.

[pBS]

yea,i know about those...those normally come across when just playing a file from the network, but this traffic is beyond the norm, like something on the server needs feedback on the stream's position or something, maybe OSD..

don't see why it doesn't happen on finished recordings, but only on in-progress ones..even if played through video library...but with a different parser,it works fine and tons less trafffic but we lose the ability to ff/rw.[unreg gbpvrparser.ax]
narrowed it down to the way the parser handles ff/rw on live streams...everything else works as expected...

it's almost as if it's sending the whole file back to the server as it plays it..

i suspect it's something sub will have to fix..and he hasn't made changes to that file in ages and i know it's not high on his todo list so just glad i got it working this much...
thanx for the help tho...

[sub]

The one major difference between the Microsoft demultiplexer and GB-PVR parser, is the GB-PVR parser regularly seeks to the end of the file and re-reads the timing information to determine how long the stream is. This is done so your can ff/rw/seek within the video file whilst it is still recording. This will most likely account for some of the additional traffic you see while playing a video which is still recording.

I'm assuming your comment about 'as much traffic back to the server' was just a guess. I cant think of anything that would cause that. I'd expect seek commands and SMB ack's and other control stuff, but not large packets like the content going to the PC.

The GB-PVR Parser uses minimal amounts of buffering to ensure that it does take too long to change channels, but this is sort of at odds with trying to run across a network, which is the most likely reason you see stuttering.

[pBS]

yep,ya got me...was jsut guessin and had an idea it wasn't sending the same amount back,but it was sending exactly the same number of packets, which isn't normal...but that explains it...i wonder how VLC does it's in-progress stream playing...guessing it's really hard to do as very few other players besides vlc can play them either...
hmmm,maybe there's an answer in the packet size values or MTU or buffering..

thanx for the info,will keep me from going down dead ends...

MVP still rocks for multi access and from the press sheet on the new wireless one it will have spdif and rgb outs... [and hopefully their alliance with Replay people and their linux experience will bring us some new dongle.bins]
but it's probably just a vaporware 'option' incorrectly quoted in the press sheet..lol

cool,should be able to optimize the net enough to raise the recording rates now i know what's flowin thru...

back to programming the remote on the new client...

[Hayden]

I've created a tool that might help people set this configuration up.

You can see it here http://forums.nextpvr.com/showthread.php?p=98782

[MDs]

I wanted to know if you can watch your recordings over the internet like MythTV

[stefan]

If you install VLC, you can using the web interface (I don't know how myth does it so it might or might not be what you want...)