Carsten Koch wrote: ... > I noticed that updating the recordings menu is still very slow. > Caching the data of course did speed up things, but vdr still > has to scan when /video/.update was touched (after an external > change), when it starts up, etc. Also, this has been a workaround > at best against the two basic flaws: > > 1) when replaying or recording, VDR floods the linux file system > cache somewhat needlessly with data that do not need to be > cached since they typically do not get read again while they > reside in the cache, thus slowing down the intire system and > not leaving room in the cache for even the directory entries, This has been fixed nicely by Ralf M?ller's new "vdr-avoidTrashing" patch, see http://vdr.unetz.com/download/patches > 2) vdr's recordings scan is slowed down further by the fact that > VDR opens all resume.vdr files to see if the recording is rewound. > This problem can be greatly reduced by two steps: > a) Remove the resume.vdr file if it points to (almost) the > beginning of the file. Attached is an updated version of my patch for VDR 1.3.30. > b) Never try to read it. If the directory entry is there, > with the above patch it can be assumed that the recording > is not rewound. This still needs to be done. Any volunteers? Carsten.
