VDR User wrote: > On 1/31/07, *Klaus Schmidinger* <Klaus.Schmidinger@xxxxxxxxxx > <mailto:Klaus.Schmidinger@xxxxxxxxxx>> wrote: > > VDR User wrote: > > From what he's saying, the problem is buffer overrun's, not > underrun's. > > Too much data is being sent and the device isn't able to keep up. If > > that's the case then it would make sense for vdr to have a user > setting > > to limit how many seconds (or milliseconds perhaps?) worth of data is > > sent to the buffer. I can't think of any reason not to add such a > > feature if it means better usability for the end-user. > > If the device can't take any more data, it should just refuse to > accept it and return from the write() call without anything written. > > > I disagree. Simply returning from write() implies the data was written > and the device is ready for more. The write() function returns the number of bytes actually written, which is not necessarily the same as the number of bytes the caller wanted to write. So the device can chose not to accept all of the data. If the device is currently unable to accept any data (and the file handle is in O_NONBLOCK mode) it shall return EAGAIN to inform the caller that it is currently busy and that the caller should try again later. > If this is not true then you risk > making the sync even worse. 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'm following up on that now. Well, that's exactly what I was suggesting. The write() function has everything it takes to block data from coming into the device if its buffer is full. No need for the caller to do any funny estimates here. Klaus
