[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Sun Jan 28, 2007 at 09:14:53PM -0500, f-myth-users at media.mit.edu wrote:
>> From: Chris Pinkham <cpinkham at bc2va.org>

> As a stopgap until the real fix goes in (or as something I might be
> able to do immediately to my .18), do you or anyone have any idea what
> -not- writing recorded.filesize will do?  If it's a complete nonstarter
> 'cause it'll break everything else, fine, but if it would be possible
> to just patch out that pair of lines you indicated and live with it
> until the table locking gets sorted out, well...

Shouldn't cause any big issues that I know about.  The recorders should
be doing one final curRecording->SetFilesize() when the recording is
done anyway.  The filesize is updated during recording for a couple
reasons including if the backend is stopped prematurely, that is part
of the reason we write out the seektable while recording also.  The
seektable is also written out so that a player can get the seektable
from the DB without having to request it from the backend.

There is code in mythbackend to fill in the filesize if it is missing
whenever the frontend requests the list of recordings, so if you view
the list of recordings while a recording is in progress, the filesize
field will be populated with the current filesize which will then get
updated with the final filesize by the recorder when the recording ends.

Before the filesize was stored in the database, the master backend would
have to check the filesizes of every recording whenever the recordings
list was requested by the frontend.  So if anyone thinks it is slow to
start up the Watch Recordings screen now, think about how it was back
then when the backend had to stat every recording's file to get its
filesize before returning the recordings list. :)

--
Chris