[vdr] DeleteResume patch for vdr 1.3.32.
Klaus.Schmidinger at cadsoft.de
Sun Sep 11 18:07:28 CEST 2005
Carsten Koch wrote:
> Klaus Schmidinger wrote:
>> The reading of the video directory is going to be
>> put into a separate thread, so that the user won't experience
>> any more delays, anyway.
> I hereby volunteer to beta-test that change. :-)
> I currently have 519 recordings on 9 disks.
> Even with my patch it takes 30-40 seconds to bring up
> the recordings menu.
> So some of my family members often inadvertendly start
> the first recording in the first folder because they keep
> pressing OK thinking VDR did not receive the previous OK
> I still believe that your original concept to store all
> data to be displayed by the recordings menu is better
> than a concept that requires not only directory entries,
> but also files to be read for building the recordings menu.
> Of course, aside from reducing the time to build the
> recordings menu, several things can be done to make
> the problem I am seeing at least look better:
> 1) The recordings menu could come up immediately when OK
> is pressed and fill in its contents in parallel.
> (I guess this is what you are planning to do with
> the separate thread)
> 2) You could make two passes and read only directory
> entries in the first pass and resume.vdr files in
> the second pass.
Well, depends on how good 1) will work.
> 3) You could spawn a separate thread for every disk
> you process, so waiting for 9 disks to spin up does
> not take 9*spinup_time, but only 1*spinup_time.
Since it's going to happen in background I guess this
shouldn't be that much of a problem.
> 4) Of course, Ralf Müller's "Patch to avoid file system
> buffer trashing" will also help a lot.
Certainly - I just haven't had time to look into it, yet.
More information about the vdr