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
