[mythtv] Scheduler needs table keys?
cpinkham at bc2va.org
Sat Mar 3 06:37:25 UTC 2007
* On Fri Mar 02, 2007 at 10:48:59PM -0500, f-myth-users at media.mit.edu wrote:
> replying to here), but while I wait for that, here's some operational
> experience with cpinkham's suggested patch to ProcessData:
> It works!
One might almost think that I actually wrote some of the code in question. :)
> I commented out -only- the setfilesize call there (and not at
> FinishRecording). As expected, the first time either the frontend or
> Mythweb looks at a recording in progress, it updates the filesize, and
> that size stays frozen until the end of the recording. The only time
I've committed this change along with a fix for this 'frozen' filesize
issue to both trunk and -fixes. The backend will not update the filesize
in the DB while the recording is in progress, so it will always look up
the current filesize when you request the recordings list. Once a
recording finishes, the recorder will update the filesize. If for some
reason this doesn't happen (ie, if the backend was stopped or crashed
before the recorded.filesize field was filled in), then the backend
will update the filesize in the DB if the filesize is 0 and it is
currently past the recording's endtime.
> Conclusion: Chris nailed this precisely. Thanks!
I'm glad it's corrected the issue. I've seen occasional glitches in some
of my recordings that I may be able to attribute to the contention on
the recorded table.
> Recommendation: I'd advocate making this patch to SVN immediately.
I've been debating doing this, but wanted to work around the frozen
filesize issue first. I had the idea in my head but didn't have enough
time until the past day or two to mess with it.
> Yes, it will break the ability to track in real-time the growing size
This shouldn't be an issue with current SVN trunk or -fixes because of
the logic I described above.
> Yes, I know that there is a pending change to the whole way this value
> is used (e.g., moving filesize out of recorded entirely, so it doesn't
This is near the top of my TODO but it may be a month or two before I get
it in because of some other things at the top.
> P.S. This took forever to test because I had to build a test system
Thanks for testing and confirming the theory.
> production machine despite my precautions to avoid it. I'm mentioning
> this as yes another plea for CONFIRMATION before an auto-schema-upgrade,
> unless there's a flag set in the database that says, "Yes, I'd like to
> live dangerously." It would have made my testing much easier if I
> could have depended upon that behavior.]
A hack for this would be to set your DBSchemaVer in the settings table to
something like '9999'. Myth won't do any upgrades until you set it back
to the proper version (better write that down). :) How to do this is left
up to the reader and would be totally unsupported.
More information about the mythtv-dev