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