On Sun, 11 Sep 2005 18:00:15 +0200, Carsten Koch wrote: > I hereby volunteer to beta-test that change. :-) Me too! ;-) > > I currently have 519 recordings on 9 disks. 599 recordings on 10 disk > Even with my patch it takes 30-40 seconds to bring up > the recordings menu. Only for the first time. I currently see much more delays because vdradmin scans the schedule for autotimers. > 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. Here I miss the message that the recordings are being scanned as it was in the old 1.2 version. > 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. I agree. If this could not be avoided that it would be ok to cache the content of the resume file as with all the other infos. > 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) Yes, this would be ok. > 2) You could make two passes and read only directory > entries in the first pass and resume.vdr files in > the second pass. It should be done in a single pass because the directories have to be read anyway. > > 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. I would disable spin up/down of disks anyway. And vdr doesn't know what disks are involved. Emil
