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)
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?
Carsten.
