[vdr] cUnbufferedFile and NFS mounted video dir

[Artur Skawina]

Klaus Schmidinger wrote:
> Artur Skawina wrote:
>> i did the minimal fix to the existing vdr code -- note it's far from 
>> optimal,
> 
> Well, this is pretty much the killer argument against including it for
> version 1.4, I'm afraid.

I probably should have been more specific wrt the "far from optimal" part -- 
it's about the Read() calls only. The Write() part, which is what this thread 
was about, and what caused me to make the patch in the first place, is working 
perfectly AFAICT.
IOW simply omitting all of the the USE_FADVISE Read() code (making it basically 
a simple safe_read() again) would be a safe fix; see below however.

The problem with the read side is that the uncaching is much too aggressive, and 
while it works when there's no IO load, it causes large delays when replaying a 
file while some other disk activity is going on. This is what the comment block 
above cUnbufferedFile::Read was referring to. While testing yesterdays patch i 
accidentally found a way to reliably trigger the problem and verified that 
disabling fadvice in Read() makes the delays go away. Will replace the 
complicated read() accounting with much simpler version and post a patch later 
today.

> gracefully by any file system, so the sole benefit from cUnbufferedFile
> would be not to clutter the file system cache, but that's probably

much smoother writes is another benefit, and one, once gotten used to, even more 
  valuable.

> no longer such a big problem since VDR caches the recordings data
> and thus can bring up the Recordings menu immediately, even if
> recordings are currently being made.

in the NFS case rereading the dir tree takes quite some time (eg ~8s here) even 
when it's fully cached on both nfs client and server -- so caching it internally 
helps a lot.

artur