<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 2, 2013 at 11:39 AM, Frank Schmirler <span dir="ltr"><<a href="mailto:vdr@schmirler.de" target="_blank">vdr@schmirler.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">Hi,<br>
<br>
On Sat, 30 Nov 2013 16:36:14 -0800, VDR User wrote<br>
<div class="im">> If his recordings stream fine and the problem is only with live tv,<br>
> how could that possibly be network congestion?<br>
<br>
</div>I should have written "temporary network congestion".<br>
<br>
When streaming a recording, the client can pre-buffer data to prevent buffer<br>
underruns. With live TV this is not possible as data becomes available just in<br>
time. So fluctuations in the available network bandwidth could have an impact.<br>
The fact that streamdev uses TCP to transmit the stream might be an additional<br>
problem here as packet loss leads to retransmission.<br>
<br>
As Morfsta is able to view HD recordings while he seems to get problems even<br>
with SD live TV, bandwith alone surely isn't the problem. But temporary<br>
congestion or high packet loss due to e.g. interference sound reasonable to me.<br>
<br>
Regards,<br>
Frank<br>
<div class="HOEnZb"><br></div></blockquote><div><br></div><div>Difficult to trace these problems isn't it? I get a sustained transfer rate when copying files over of around 15MB/sec - so I would have thought this would be ample for SD and HD streaming? </div>
<div><br></div><div>I was just surprised to find very few options to play with in streamdev with regard to buffer sizes etc. I presume this is by design and the way in which it works?</div></div></div></div>