[vdr] DeleteResume patch for vdr 1.3.32.

[Klaus Schmidinger]

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
> command.
> 
> 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)

Exactly.

> 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.

Klaus