[vdr] Re: Speed of VDR 1.3.12 recording menu

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Emil Naepflein wrote:
> 
> Hi,
> 
> recently I have updated one of my VDR clients to 1.3.12 to see how the
> improvements are. The stability of this version is already good and the
> new functionality is nice. But, I recognized that there is still one
> issue I already had with the old version.
> 
> The speed of the update of the recordings menu is still very slow in
> some cases so that the response time of VDR is very large. Please notice
> that I have more than 500! recordings on the server and the client has
> access to this by NFS over 54 Mb WLAN. So this is a worst case scenario.
> 
> After startup of VDR it immediatly loads the recordings. This takes
> approximately 10-30 s depending on the state on the server. If the
> server has to read the tree from disk it is the longer time. As my
> clients are turned off after use, it is really annoying to have to wait
> so long even someone wants to view TV only.
> 
> One thinks, ok if everything is loaded during startup then the recording
> menu should come up immediately. But, when I access the recording menu
> it takes approximately 10-15 s until the recordings menu appears. As
> there is no OSD output and VDR doesn't respond to any IR command it just
> looks like VDR is dead. The reason for this additional delay seems to be
> the read of all resume files in order to display the new indicator.
> 
> I have also noticed that some minutes after startup VDR scans the
> recordings again, even the .update file didn't change. During this time
> VDR is dead. This is caused by the call to RemoveDeletedRecordings().
> This takes more than 70 s because the algorithm used in ScanVideoDir()
> doesn't stop when a directory ending with ".rec" is found. So this scan
> reads all the directories.
> 
> So, how could that all be fixed?
> 
> Here are some ideas:
> 1. Stop search in ScanVideoDir() when a directory is reached that is
> ending on .rec or on .del.
> 
> 2. Update both recordings and deleted files in one scan.
> 
> 3. Read resume status in ScanVideoDir() and update the status on every
> change of the resume file.
> 
> 4. After startup don't do the Load in one step, do only partly every
> second. Only if someone wants to view the recording menu then finish the
> scan.
> 
> 5. Display OSD before starting Load to give the user a response.
> 
> 6. When stopping save the current recording list to disk and read it
> after start.
> 
> 7. For client/server setups it would be nice to be able to read the
> recording list through svdrp from the server. This would be much faster
> than through NFS.
> 
> Any further ideas?
> 
> I think it is very important that all the information displayed in the
> recording menu is cached and updated internally on changes (resume,
> deleted files, ...).

I'm currently busy trying to improve the buffer handling to avoid oberflows
when several recordings are going on.

I'll take care of the recordings menu probems later.
The current caching mechanism was just a first step.

Klaus