On Wed, Jan 31, 2007 at 08:38:29PM +0100, Klaus Schmidinger 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 gather that in plugin-based playback, cDevice::PlayAudio() and cDevice::PlayVideo() are overridden and may return 0 to indicate that nothing was written. I modified PlayAudio and PlayVideo in softdevice.c so that they return 0 when softdevice is in suspended state. That is, I replaced if (! packetMode) with if (!packetMode && !setupStore.shouldSuspend) in both methods, so that they would return 0. This seemed to work for recordings, but I am not sure if it worked for video. If I suspended the playback for only a short while, it looked like the playback resumed from where it was stopped, and maybe some frames were dropped every now and then to reduce the lag. I'd prefer the live playback to resume without any lag, that is, to drop all live PES packets during the time the playback was suspended in the plugin. However, the PES packets from recordings should be blocked. I believe that the easy fix would be to have these methods return 0 only when playing a recording. Can the plugin detect this somehow? Marko
