[vdr] DeleteResume patch for vdr 1.3.32.

[Emil Naepflein]

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