[mythtv] Scheduler needs table keys?

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

    > Date: Sat, 03 Mar 2007 03:28:41 -0500
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > If it's mythtv-setup, only, we'd have a long road to walk teaching 
    > people to run mythtv-setup every time they upgrade.  And then we'd get 

-Only- if the "live-dangerously" switch isn't set!  People who routinely
update from SVN would presumably set the switch, and the MBE would
upgrade itself every time you pulled & compiled a new SVN and started
running it.

The non-SVN users who upgrade by releases, often from packages, should
certainly expect to run mythtv-setup when they do.  And the backend
can enforce this by refusing to run until that happens (presumably
also spitting out a big warning to stderr -and- syslog saying, "Hey,
the "be safe" switch is in its default position, and you've clearly
upgraded, so go run mythtv-setup first").  And remember this only
happens on upgrades---a brand new installation on a machine that's
never been installed on before presumably works the same way (but
presumably it's even -more- important that the backend encourage the
user to run mythtv-setup in that case :).  And packagers can be
provided with a script they put in postinstall that says "Remember to
run mythtv-setup before trying to run the backend or it won't work".
(It could run it -for- you, but right in the middle of an apt-get is a
fairly inconvenient time for that sort of thing; postfix's postconfig
menu is irritating enough.)

    > the pundits on the list encouraging others to be lazy by saying, "Well, 
    > since you're upgrading from r19872 to r19893, you don't need to run 
    > mythtv-setup first, but if you were upgrading to r19894, you'd need 

Won't happen if SVN users set the switch to "dangerous".

    > to..."  IMHO, when those messages start appearing--and unsuspecting 
    > users take them as upgrading instructions or, worse, official 
    > recommendations--it would be far worse than the current situation (i.e 
    > "Welcome to the ranks of SVN trunk users.  Please ensure you sign up for 
    > the mythtv-dev and mythtv-commits lists and read all the messages, since 
    > SVN trunk users are expected to keep up.").

AKA "You've just screwed up, and there's no way back, so NOW we hope
you like dedicating a few -hours- a day until the next major release,
possibly most of a -year- away, to reading two mailing lists you
didn't want to be on, as a constant reminder that you screwed up
and our software didn't make the slightest attempt to keep you
from doing so."

All because you accidentally pulled the wrong version, something we've
seen even experienced packagers do.  Or perhaps because a friend
visits with Myth on his laptop and you're foolish enough to let him
connect to your backend to watch something from your collection.

That's a pretty abusive user experience, if you ask me.

    > If the master backend is allowed (or also allowed, along with 
    > mythtv-setup) to upgrade the schema, the change would have no effect on 
    > users of combined frontend/backends who "test out" SVN trunk or a 
    > "one-time" build of -fixes and then try to go back to using their 
    > packager-provided -fixes build.  Generally, I think the only people it 

Again, you -default- the switch to -safe-!  Then those who "test out"
either get an immediate exit (safe, but annoying & a debugging issue)
or a popup/alert/mythtv-setup/whatever saying, "Hey!  This version
can't run unless it upgrades your DB!  That's a one-way street!  Are
you -sure- you want to do this?  If so, what's 2 + 2?"  (The idea of
the latter is to avoid the "automatically click/type Y to any popup"
effect; we've used it on various mission-critical things and it's
really saved our bacon.)

    > would purport to "help" are the people who should know better (i.e. 
    > those running multiple frontends/backends are more likely to know a 
    > thing or two about Myth...).  They should at least know that upgrading 
    > is a one-way road; should probably know that all frontends/backends must 
    > be running the "same version" of MythTV; and possibly may know how to 
    > create a test/dev system that doesn't hit the same database...

The problem is -not- "I'm upgrading and I know it".  The problem is -either-:
(a) "I didn't -think- I was upgrading, but I somehow pulled the wrong version"
(b) "I'm running a test, and I -think- I got it right, but oh SHIT!  I forgot
    to change the IP address for the backend!"

E.g., the entire problem I'm advocating we fix is ACCIDENTS.
You can't just say "be smarter".  You have to mitigate the
damage, because everyone screws up eventually.

My impression is that we see a post every fortnight from someone who
accidentally ran a newer version than they thought they were going to
run.  And those are only the people who bother to send mail; it
doesn't include the ones who know they're screwed but don't bother
to tell everyone else because they know what happened.

    > Personally, though, I don't care either way--it won't affect me because 
    > I do and will understand the issues and the proper procedure for 
    > upgrading (not to mention the three pieces of info I discussed above).

You're -so- not the "target market" it isn't even funny.

In fact, your response is one of the most frustrating things about
trying to say -anything- about usability when it comes to Myth:  it's
pretty much guaranteed that some developer/expert user will say, "Hey,
-I- can do it, so it must not be a problem."  By definition, most
users are -not- at that end of the bell curve---and hence will make
mistakes (and generate a lot of list traffic) even if it was
theoretically possible for them to have done the right thing.