[mythtv] Scheduler needs table keys?

[f-myth-users at media.mit.edu]

    > Date: Sat, 3 Mar 2007 01:37:25 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * 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. :)

*snerk*

OTOH, I'm a paranoid sort.  I've been wrong about code I've written
often enough that I'm a big fan of testing it all, whether it's mine
or someone else's. :)

    > > 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.

Yeah, I saw the commit comments.  (My one question ['cause I haven't
actually read the code in question]:  what's the precise definition of
"endtime"?  The time the program was scheduled to end with, or without
padding, and what if it was prematurely stopped by the user?  Not that
this seems likely to be a big issue, because -eventually- we'll be
past it no matter exactly how it's defined, and a crashed/stopped
backend should be infrequent.)

    > 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.

Yikes!

Wow, that made my skin crawl, but I've certainly done worse.
(Remind me to tell you someday of the entire full & incremental
backup system I wrote in VAX/VMS DCL a long, long time ago for a
rather large company back before DEC had a credible solution of
their own, and the night security guard I then trained to run them... :)

But sure, that might be an interesting stopgap, at least for me.
I already maintain my own private version of DBSchemaVer (called
MyDBSchemaVer or somesuch) to track the alterations I've made in Myth's
DB (I added a few columns to oldrecorded, all starting with "_" to
avoid name clashes with later updates).

I still wish this was a supported part of Myth, though. :)
These rogue updates (e.g,. new frontend smashes the backend)
generate a fair number of "d'oh!" messages to the list and no
doubt quite a bit of headache for those who trip over them.