[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Tue Feb 27, 2007 at 03:31:12AM -0500, f-myth-users at media.mit.edu wrote:
>     > be doing one final curRecording->SetFilesize() when the recording is
>     > done anyway.  The filesize is updated during recording for a couple
> 
> In my test system, it's not getting set at the end, since you
> suggested commenting out -both- occurrences of SetFilesize; one

Yes, it was a test, not really meant for production.  I think I suggested
that before I actually confirmed in the other thread that it was the
scheduler effectively locking the recorded table which prevented the
filesize from being updated.

> is in ProcessData, but the other is in FinishRecording.  Did you
> mean to totally inhibit the latter, or did you just not notice
> that one of the calls was there?

There is code in the backend to update the filesize in the DB if a recording
has a filesize = 0.  I think this code has been in there since I first
added the filesize field to the database because we needed to populate the
filesize for old recordings.  I just set all the filesizes on my dev system
to 0 and went into the Watch Recordings screen and now the recordings have
their filesize populated in the database again so this code appears to be
working correctly in trunk as well.

> In an unmodified system, recorded.filesize gets updated every 15
> seconds, which makes sense if it happens every 30 keyframes.

Yes.

> In my test system, recorded.filesize starts out 0 when a recording
> commences, and is modified to the current filesize the instant the
> frontend looks at it (e.g., the first time I go to the listing of
> what's been recorded---I did this a minute or so into a 5-minute
> manual recording).  At that point, nothing I do, including skipping
> around in the recording, leaving and reentering that frontend page, or
> even terminated and restarting the frontend, causes the value to
> change.  [This is really easy to demonstrate; I just put the relevant
> SQL query in a one-second loop in a shell and watched it in another
> window while playing around.]  Obviously the frontend sees a value
> there and never tries to update it.

OK, so this is a negative side-effect of removing those calls to
SetFilesize().  The frontend doesn't actually update the filesize,
the backend does, but once it updates it once for a running program,
it will never update it again since the value is now non-zero.
If you want to work around this in your tree, you can look in
mythtv/programs/mainserver.cpp and look for calls to SetFilesize and
comment those out as well.  This will cause the backend to look up
the current filesize on the filesystem, but it won't write it out to
the database.  This is at the expense of load time on the Watch
Recordings screen though because the backend will have to stat every
file which is the way things used to work a few years ago.

> I noticed that -something- split out an error flagging my test
> video about "MPEG motion vector out of boundary" and "concealing 45
> DC, 45 AC, 45 MV errors" (and some other warnings in between).  I

Data corruption, nothing to do with the filesize in the DB.  Very
little code actually looks at the filesize field, it is mainly used
for the Watch Recordings screen.

> Note:  if not having the filesize set -is- causing commflagging to
> barf, I need to know in order to tell commflagging not to start until
> the recording is finished.  (Right now, it runs concurrently.)

Shouldn't be, a "find ./ -name '*.cpp' | xargs grep filesize" shows
very little places using this value.

> So the big question:  Do I care that recorded.filesize won't -ever-
> get updated to the "final" value?  What looks at it?  Or should I
> only remove the use in ProcessData and leave FinishRecording alone?
> [I'm assuming that, by the time that's running, we've read all the
> ivtv buffers we ever will, so it doesn't matter if -that- hangs for
> 30+ seconds if the scheduler is already running; is this correct?]

It should be safe (and better) to only remove the one in ProcessData,
that way even if the backend sets the filesize in the DB, the recorder
will update the value to the final filesize when the recording finishes.

--
Chris