[vdr] DeleteResume patch for vdr 1.3.32.

Carsten Koch Carsten.Koch at icem.com
Sun Sep 11 18:00:15 CEST 2005

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.

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.

4) Of course, Ralf Müller's "Patch to avoid file system
    buffer trashing" will also help a lot.

What do you think?


More information about the vdr mailing list