[mythtv] file checks in HandleQueryRecordings

[Chris Pinkham]

* On Wed Nov 22, 2006 at 01:48:17PM -0500, Tony Lill wrote:
> What is the purpose of checking for the existence of the recording file
> in the main loop of HandleQueryRecordings? In my setup, this has the
> unfortunate effect of mounting nfs partitions and spinning up disks that
> don't need to be spun up. This contributes to the huge delay in getting
> the watch recording screen to display, as well as making my attempts to
> spin down idle disks pointless.

If you're running current SVN, the delay should be much shorter than it
used to be because the frontend will cache the list in most cases instead
of re-retrieving it from the master backend.  The recordings list cache
has been in SVN for a few months now I think.  It made a lot of actions
on the Watch Recordings screen much quicker.

This part of the code in HandleQueryRecordings has been mostly
rewritten as part of my Storage Groups patch, and the new method doesn't
check for the file.  The main reason for checking was the
MasterBackendOverride setting which allows the master to stream files
for slaves if it has access to the file locally.  In my code, I've
pushed that check off until later because it doesn't sense to check
for every file when very few (possibly none) will be acted on by this
filling of the recordings list.  If the player decides to play a file
and MasterBackendOverride is turned on, then GetPlaybackURL() will ask
the master if it can stream the file and if so the myth:// URL will
point to the master, otherwise the myth:// URL will point to the backend
that recorded the file.  So the file existence check is never
done for most files unless you actually play them.  The only time it
should occur in HandleQueryRecordings is if the filesize is 0, so that
we can fill the size in.

--
Chris