<div><span class="gmail_quote">On 1/31/07, <b class="gmail_sendername">Klaus Schmidinger</b> &lt;<a href="mailto:Klaus.Schmidinger@cadsoft.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Klaus.Schmidinger@cadsoft.de
</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
VDR User wrote:<br>&gt; From what he&#39;s saying, the problem is buffer overrun&#39;s, not underrun&#39;s.<br>&gt; Too much data is being sent and the device isn&#39;t able to keep up.&nbsp;&nbsp;If<br>&gt; that&#39;s the case then it would make sense for vdr to have a user setting
<br>&gt; to limit how many seconds (or milliseconds perhaps?) worth of data is<br>&gt; sent to the buffer.&nbsp;&nbsp;I can&#39;t think of any reason not to add such a<br>&gt; feature if it means better usability for the end-user.
<br>
<br>If the device can&#39;t take any more data, it should just refuse to<br>accept it and return from the write() call without anything written.<br></blockquote></div><br>I disagree.&nbsp; Simply returning from write() implies the data was written and the device is ready for more.&nbsp; If this is not true then you risk making the sync even worse.&nbsp; 
I consulted with people familiar with this type of stuff and it was suggested the problem could (and should) be fixed at the driver level so I&#39;m following up on that now.&nbsp; Hopefully we&#39;ll find a good (or at least resonable) solution to this last little bit of a/v sync frustration.
<br>