[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Thu Mar 01, 2007 at 12:32:09AM -0500, f-myth-users at media.mit.edu wrote:
> Btw, realizing this the other day made me realize one reason why this
> corruption is so unpredictable---not only does the scheduler lock that
> table for widely varying amounts of time for no reason I've seen (I'm

<snip>

Makes sense.

> -My- Watch Recordings screen doesn't seem to need to know the filesize
> -anyway-, since there's nothing there that mentions it!  I use G.A.N.T.

It's on the Delete Recordings screen actually, which is actually most of
the same code that the Watch Recordings screen uses.  I've often thought
of making those screens more themeable, I never use the Delete screen
but sometimes would like to see filesizes.  I know this is now available
via the recording info popup, but I figured theme designers might want
disk usage stats on the Watch Recordings screen for people that never
use the Delete screen like myself.

> [Is there an opportunity here to only compute this data if the theme
> requires it?  Such lazy evaluation might be handy for others.  OTOH,
> as long as keeping it updated doesn't cause these buffer-thread/scheduler
> deadlocks, I don't really have an opinion on this...  Hmm, and I guess
> MythWeb needs this info somehow; I'm assuming it's using that field.]

The Auto Expirer is the biggest user of the filesize information since it
needs to know how much space will be freed up if it deletes a recording.
It also doesn't want to have to stat the files all the time to find out
how big they are.

> there's no way that mainserver could lock up the table long enough to
> cause dropped data, but I'll test it by rebooting a frontend and
> selecting Watch Recordings while something is recording, and see
> if that corrupts it.  [Can you think of a more-strenuous test I should
> try instead?]  If not, I'll leave it alone.

Mainserver should be doing queries mainly so it won't lock, although it
might get locked.  It does update the filesize, but that only takes
a short while, so a long query running somewhere else (ie, the scheduler)
with a parallel SetFilesize() call in mainserver, could cause another
query to block waiting for the set to finish (which is waiting on the
scheduler's query to finish).  I tested and documented this scenario
in the other thread a while back.

> Ok.  I didn't happen to run that grep 'cause I simply assumed that it
> was some critical value or it wouldn't be getting updated so religiously. :)

One of the big reasons originally was to allow people to not get useless
info for a corrupted/unfinished recording.  That is why we write out the
seektable frequently as well in case something happens on the backend.
You can also see the filesize growing on the Delete Recordings screen if
it is refreshed during a recording.

--
Chris