[mythtv] Scheduler needs table keys?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sat Mar 3 08:05:44 UTC 2007

    > Date: Sat, 3 Mar 2007 02:31:59 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > But then we'd have just as many people asking why their backend won't
    > startup because they need to go modify some startup script to force it
    > to allow automatically upgrading the schema, then they have to remember
    > to restart the backend after removing the command line argument and
    > restart again or else the next DB upgrade would be applied automatically.

"--once" ?

    > I can see an argument for making it so that only the master backend
    > or mythtv-setup would automatically upgrade the DB while slave backends
    > and the frontend would exit and print an error message about the DB being
    > the wrong/old schema version, but I'm not sure if that idea would be
    > accepted.

I think I made a similar proposal a while ago, but it sank without a
trace.  The idea was "nothing but the MBE can cause a schema update,
unless you've set 'Yes, I like to live on the edge'."  With perhaps
other settings for "Allow a new MBE to do the update" or "Only allow
an update if I run mythtv-setup"---the latter is the safest, because
mythtv-setup has a UI (!) so it can -ask- you if you know what you're
about to do.  (Hey, maybe it can even offer to back up your database
-first- in case something bombs or you change your mind!  How radical
is -that-?  I mean, hey, checkinstall at least does -that-... :)

The idea here is that people who are constantly running SVN set either
option #1 or #2 so they don't get annoyed, but the default is #3.  If
you're downloading a new release and installing it as MBE, you presumably
know you're probably going to have to configure something.  And people
who package releases can force the issue by having the postinstall for
the package run mythtv-setup, or -something- that will present the
user with the "really update your database, or abort this installation?"
question unless their DB already has the "live dangerously" setting.
(Ditto w/a DB backup as pre- or postinstall...  hmm...)    

But I also said at the time that -I- was unlikely to work on this
and was hoping I could persuade someone else, for two reasons:
(a) I was reluctant to come up w/a patch and then discover that the
    whole -idea- was unpopular with the devos, hence wasting my time
    ---if the patch isn't in the -released- version, it's worthless!
(b) I -certainly- wasn't going to be working on it here, since I'd
    need one and maybe two test machines that I could -guarantee-
    couldn't accidentally (through my own stupidity or misconfiguration)
    talk to my production machines and update them.  Which probably
    meant a totally separate network.  (Sure, I could just get another
    switch and put them on it, but still...  it's a big investment of
    time & HW compared to what someone who routinely runs SVN could
    do without changing their configuration at all, if they were
    inspired to work on it in the first place. :)

P.S.  This would be a lot more of a nonissue if a DB update wasn't
such a one-way trip.  But since so many things can do it right now
(-any- mythtv program: front, back, or setup), and since it's
obviously a source of confusion exactly what version you're on when
you include, e.g., the -fixes branches vs non-fixes releases vs trunk
vs packages (we've seen lots of confused mail from people---even the
KnoppMyth maintainer got this totally wrong and pushed out an
SVN-based version without even knowing it, around the time I first
tried to install KP 16 months ago), it looks like it's causing a lot
of accidental (and sometime even undetected) updates and a lot of grief.

More information about the mythtv-dev mailing list