[vdr] DeleteResume patch for vdr 1.3.32.
Emil.Naepflein at philosys.de
Sun Sep 11 20:16:30 CEST 2005
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
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
> 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.
More information about the vdr