[mythtv-users] MythTV Installer Usability: An Analysis

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Nov 4 02:18:27 EST 2005


    Date: Fri, 4 Nov 2005 00:47:42 -0500
    From: Dewey Smolka <dsmolka at gmail.com>

Just a meta-comment here:  If you dismiss every possible complaint
with, "you're a moron for even suggesting that this is a problem,"
then, no, I guess there are no bugs here.  But let's assume that,
despite appearances, this wasn't actually what you are trying to do.

    Of course, most people will never see it at all because a PVR,
    particularly MythTV, isn't really designed for live TV, and certainly
    not for 5.3 hours of live TV.

Sure.  Until you happen to, say, leave it set on live TV, turn off the
television, and go to bed.  (That's not what I did, but I figured it
wouldn't hurt to -test- that possibility.)

Then, when you wake up in the morning, your machine is totally
screwed---not only will any scheduled recordings on other tuners have
(probably) gotten trashed due to thrashing the disk channel, but your
UI is stone-cold dead and unresponsive until you reboot, and any other
FE's depending on this BE are broken, too.  This isn't my idea of the
sort of reliability an appliance should have.

Even better, since you probably won't remember that that's what you
did (or perhaps what some other family member did), it will just keep
-happening-, at random, just often enough for you to decide that the
whole thing is hopelessly buggy and annoying and not worth dealing with.

Terrific.

    <snip>
    > (S-2) The SQL database is being mis-initialized, or whatever is
    > using it is becoming confused, in a way which is causing brand new
    > installations to fail, in the case where the backend and the frontend
    > are different machines.  The failure typically manifests as follows:
    >
    > The frontend can talk to the backend's SQL server enough to initialize
    > when mythfrontend is run, and the backend's SQL log will emit 100+
    > lines of logging.  However, selecting "Watch TV" on the frontend will
    > yield an instant error claiming that the frontend can't talk to the
    > backend, and, if "mythfrontend -v all" is being used, you'll see
    > errors in the shell it's run from claiming that it's trying to talk
    > to localhost instead of the backend machine.  Fixing this involves
    > bashing a NULL into one of the rows of the backend's SQL database!

    Never seen this, but then again, I like to make sure that my BEs are
    properly set up and network addresses properly set before adding FEs.
    The steps are fairly well documented.

The BE -was- set up first.  It has to be, after all.  And all network
addresses were correctly set.  The problem came in -then- setting up a
FE that could talk to the BE.  THIS IS A BUG---and a new one, apparently.

If you follow the URL I provided, you'll also find half a dozen other
people who got screwed over by this behavior, and an unknown number of
others who read the thread and fixed their own problems without
posting.  The thread has -thousands- of views, and generated a few
hundred posts.  It's a real issue.  It seems to be new in KnoppMyth
R5A22 (it didn't screw people in the previous release, which was A16),
and probably only happens if you're installing from a blank slate
(which may be why KP's maintainer couldn't reproduce it and claimed
that everyone just couldn't read the instructions---until the bug and
a workaround was produced that solved the problem for all those people).

    > (S-3) The installer's default choice of monitor sync rates isn't
    > conservative enough.  This came up (I think!) because I'm using a
    > crappy old video card to do my installations, because I -know- that my
    > real frontend is going to be the video-out on a PVR-350 and my -good-
    > cards are in other machines.

    Why would you have a PVR-350 in a front-end? If it's capturing, then
    it's not a FE. If you're going out to a monitor, you're not using the
    350. Why use a 350 at all when you can get just as good a picture for
    less money with a cheap nvidia card?

The 350 will eventually also be capturing, and the FE will thus be
transformed into a slave backend via some setup & NFS links, as is
documented in mysettopbox.tv/linhes.html.  (In fact, that setup is
already done, since it was easy and didn't affect debuggability; it
will probably also get another capture card or so.)  But getting the
eventual SBE set up first as an FE simplifies life and makes debugging
easier, especially since the SBE -will- be getting used as an FE
because it's the machine that will be rendering video (via the 350).

In the process of doing so, I needed to see what I was doing, until
the network was up enough to ssh into the box.  Hence the crappy other
video card.  And hence the sync problems.  And hence my complaint.  Clear?

    > picked H: 35.2Khz, V: 86.4Hz and my (fairly new ProView) LCD monitor
    > instantly choked and said "invalid refresh rate".

    You really shouldn't (can't) be sending a signal out of a PVR 350 to
    an LCD monitor. That is pointless.

I wasn't doing that.  The signal was being sent out of an old video
card, and the installer guessed wrong on X sync for the card.

    > So:  C-Alt-F1'ed and got a text console, spent a while figuring where
    > the heck an editor was

    $vi

Yeah, if you use and can stand vi.  (Please note I was attempting to
-avoid- the inevitable religious war here, and even said so up front.)

    > ANNOYING:
    >
    > (A-1) The installer asks me -twice- for my timezone and current time:
    > once, when the CD is in control of the machine, and once -again- when
    > the installation is proceeding from the hard disk.  Nowhere that I can
    > find is it documented whether either one of these queries matters.

    So skip them. There are other ways to set your system time.

Of course.  Though your typical newbie might not know 'em.  And why
present a pair of annoying, poorly-done menus -twice- if it's preventable?

    > But even given that, does
    > it matter if I ignore the timezone/date prompt from the CD, and then
    > set it correctly when running from the disk?  No idea.

    No. It doesn't matter.

About what I figured.

    > (A-3) If you mistype the root password when the machine comes up just
    > after ejecting the CD, the window simply vanishes, leaving you with no
    > installer at all.  I guessed that simply rebooting the machine would
    > rerun the installer, and it seems to have worked.

    Typing the root password carefully would take care of this problem.

Yeah, and people never ever make mistakes, either.

Especially when they're on their 8th install or so because of all the
other bugs they've been tripping over.

Really, we don't even need a rubout key, because people are also
perfect typists.  I honestly can't understand why they waste the
real estate it occupies on the keyboard.

    > (R-2) Somewhere near the end of the installation, there's a canned
    > error message that tells me to run mythfilldatabase if this is the
    > master backend---and then it immediately goes off and runs it for me.

    Yes. That is a fairly common behaviour for a script -- finish one
    thing then start another.

My point is that it would be nice to polish this rough edge off to
minimize (a) user surprise and (b) user memory.  (Why tell them they
must remember to go do something, and then immediately say, "Oh, never
mind, you didn't need to write that down, I'm doing it now, forget it!")

    > (R-3) I got the error below even though I supplied a NON-loopback IP
    > in configuration, which indicates that something is ignoring it.

    Since you're only configuring one machine, why not let it keep
    127.0.0.1 until you have everything running and can set all the
    addresses properly. Just because you tell mythtvsetup that your
    machine is 192.168.1.10 doesn't mean that ifconfig knows that.

ifconfig -did- know that, because as I was installing the machine from
CD, I told it the correct (non-loopback) address, via those detestable
obliterate-the-character-under-the-cursor text-entry boxes I was
complaining about elsewhere.  And since I knew that, the instant the
BE was up, I'd be connecting an FE to it and then turning that FE into
an SBE, why set up the network -twice- when once should work?  Plus,
there was the nagging fear that some old address would be cached
somewhere I didn't know about, like a random database field.

    >  I can't figure out
    > if the error is important or completely ignorable, though, and some
    > guidance would be nice.  (It's also got a typo in it; see "sic";
    > typos matter 'cause they make it harder to grep for errors.)
    >
    > 13:40:15.539 connecting to backend server: 127.0.0.1:6543 (try 1 of 1)
    > 13:40:15.587 connection timed out
    >                 you should probably modify the Master Server settings in the setup program and set the proper IP address

    That last line sounds like pretty good guidance to me.

But it was already correctly set.  The SQL database-initialization bug
was causing the machine to alternate between using its configured
non-loopback address, and the loopback address---this is the heart
of the bug I was reporting there, not a side-effect.  And given the
other issues, it's probably new between whatever builds were used
in A16 and A22, which means it's a regression, which means it's even
more serious, because bug regressions are an indication that something
is going wrong in QA'ing new builds, such as insufficient automation in
the testing setup.  This should be an alarm and a wakeup call that
something went wrong in the development process.

    > That error message has a couple of other problems:  It talks about
    > "Master Server" but I presume it should say "Master Backend Server" to
    > be consistent with terminology elsewhere.

    I don't really think many people are confused by that one.

Probably not, but if a trivial wording change can fix it, why not?
(Remember also that some users who may be doing this may not have
English as their native language, and minimizing potential places
where translation difficulties can arise would be a good thing,
especially if it's trivial to do so.)  It certainly threw -me- for a
few minutes, while I checked to make sure that there wasn't some weird
terminological oddity there that made a Master Server and a Master
Backend Server two different things.  I've certainly seen stupider
terminological screwups in other projects, and once burned...

    > I should note also that I saw timeouts making backend connections to
    > 127.0.0.1 as well at -some- point (but my memory is foggy about
    > exactly when---I think it scrolled by while the installer was doing
    > its thing, but of course I could neither pause the output nor find it
    > later in a file); this made me wonder if a non-loopback IP is required
    > -all the time- (despite the defaults), or if the error was spurious
    > and should be suppressed or something.

    If you had left the default at 127.0.0.1 you wouldn't have had this problem.

And leaving it at the default would have meant that I would have
immediately had to fix something later---and as a newbie to Myth,
I would have wondered whether fixing it later got -all- the places
that were supposed to know (e.g., the database!).  After all, I know
that screwing around in /etc isn't going to magically change database
fields.

Besides, presenting me with a knob, and then slapping my hand for
touching it, is incorrect user interface design.  There is a very,
very large corpus of literature on exactly this subject.

Or, in other words, if giving the machine anything but the loopback
address causes problems, then don't give the user any means to cause
the problem in the first place.  On the other hand, if it's supposed
to work, then it -should- work.  The current situation is just a bug.

    > (R-4) The "localhost" above might be related to Setup->General
    > Settings->Database Configuration 1/2 claiming "Host name: localhost"
    > even though I supplied one.  (This is a vague report, because I wasn't
    > keeping careful notes about exactly when I supplied the hostname, and
    > when I saw this error, but if it rings any bells...)  [The "localhost"
    > resetting keeps happening at various times in the install; I kept
    > having to check it to make sure it "stuck".  But it's probably
    > unrelated to the MySQL initialization bug above.]

    Again, when you install, it is to one machine. There's no reason to
    change any of the default network settings until your box is up and
    running. If you hadn't monkeyed around with it, it would have worked
    without a problem. Just because you can change something doesn't mean
    you should.

The installation instructions for setting up a split-machine
configuration very clearly state that this should be set to a
non-loopback address.  They do -not- say, "don't you dare change
this from loopback until the machine is up."  And if these sorts
of bugs were stamped out, there would be no -reason- for them to
say that, either.

    > (R-6) It would be really, really nice if Emacs could be included by
    > default in the ISO.

    #apt-get install emacs

Yeah---once the network is up.  But when I was fixing the X sync
issue, I didn't have a network yet.  Plus, I had to do an update to
get the package system to have even -heard- of Emacs, and that -first-
update had all kinds of wrong defaults that caused aptitude to try to
break the machine 'cause the KnoppMyth ISO was so out-of-date wrt the
repositories, finally forcing me to start over because aptitude had
shit the bed and toilet-training it was going to be slower and less
certain to succeed than just hitting the reset button, waiting 10
minutes, and retyping the answers to some questions.  Still think
this is so trivial?  I sure don't.

Just because I (eventually!) discovered nano preinstalled doesn't make
this whole thing go away; it just makes it somewhat less critical.
For me.  Not for somebody who's never heard of nano.  (Yeah, like
I'd guess -that- was an editor if I was just hunting around.)

    But why do you need a complete programming environment to tweak a
    couple of text files?

I don't, but it's sure handy to have the environment I'm used to
instead of a totally foreign one when I'm already hip-deep in an
unfamiliar place, and that's what Myth is to someone who hasn't
installed it before.  Emacs is also extremely good (via Dired)
at poking around large swathes of filesystem when trying to
figure out how an unfamiliar machine is configured.

    > Yes, I know you probaby get tons of requests for
    > this and that random program, but really, Emacs is the most likely
    > non-vi editor that someone might want, instantly upon or even during
    > the installation, in order to edit files to set up the machine, and
    > adding it to the ISO would only add 13.4 meg to the image.

    I'd be more concerned with reducing the size of the ISO.

Of course.  I am, too.  The question is whether the extra 14meg on the
ISO would make it too big for a 650meg CDROM, and the answer appears
to be, "not yet."  (The A22 ISO -did- grow about 100meg from A16, but
it's not at that point yet.  That rate of growth is a bad trend, though.)

One approach could always be to add Emacs until and unless the ISO
-does- cross that threshold.  And until it does, what's the harm in
having it there?

    > Making users use unfamiliar editors precisely when
    > they're in the middle of installing a new OS image is a good way to
    > get them to make mistakes.

    There's no reason why vi should be unfamiliar to anyone who has used
    Linux for more than an hour.

I've used Linux for years, but since I've used Emacs for a third of a
century (about 3 times longer than Linux has been a going concern),
I felt no pressing need to learn vi.  Do we really want to have a
religious argument about editors here?  I don't.  It's not going to be
productive, because neither one of us is going to convince the other.

    > if they don't
    > already know it, they're totally stuck and don't have any editor
    > except vi, if they can use it---which newbies can't.

    Why is it that a newbie can't use a very simple editor like vi but
    would be at home in emacs?

Newbies won't know vi either!  Newbies who have -never- used a text
editor are their own special case.  But it's -extremely- likely that
everyone who can install Myth at all has used -one or the other- of
those two editors.  It's senseless to disenfranchise a giant chunk of
the user base for no particular reason.

    > CONFUSING:
    >
    > (C-1) The default theme ("blue", with the six circles) is an
    > unfortunate choice.  Why?  Because the colors of selected and
    > unselected fields are almost identical (they're two very slightly
    > different shades of blue), and neither one screams out "selected".
    > This means that whenever I'm presented with the "erase all your
    > cards?" sorts of setup questions, I have to bounce back and forth a
    > bit with the cursor keys until I've convinced myself which one is
    > -really- the selected one.

    If you're doing a new install, you don't have any cards defined and
    you don't have any channels defined. It doesn't matter if you delete
    or don't delete something that isn't there.

Sure.  But -after- you've got some installed, you -still- have the
same damned inscrutable theme, until you change it.  And it's not just
that particular page where it's hard to see what's highlighted, of
course; that's just the first one, and the one with the biggest
hard-to-recover-from effects.

Not to mention that when I was first confronted with this menu, I
didn't think -either one- was highlighted; it wasn't clear at all what
was going on.  Perhaps my particular LCD makes those two shades of
blue difficult to distinguish.  There's also a hair-thin red line
around the selected entry that I didn't even notice for the first
couple of days; maybe that's clearer on other LCD's.  Whatever the
reason, a better choice would be some theme (or a modification of
the current theme) which uses dramatically different colors, and in
particular uses a color for "selected" which is commonly associated
with "performing an action."  G.A.N.T's choice of red is pretty good
there.  Two almost-identical shades of light blue are most assuredly not.

    > Some of the other themes (e.g., at least
    > G.A.N.T., where selections are red and nothing else is) make this much
    > more obvious, but it isn't even obvious there -are- other themes until
    > you've already configured at least once.  (I only discovered this
    > today, despite having unfortunately had to configure several times,
    > and only because of a database-connection problem that apparently
    > reset my theme from the blue circles to something else without my
    > specifying anything---boy, was -that- a shocker...)  So I'd like to
    > argue really strongly that G.A.N.T. or something else is made the
    > default theme, and not the blue circles with the hard-to-read
    > selection fields.

    The theme can be very easily set from within the FE Setup menu.

Sure can.  If you even know that multiple themes -exist-.  As a
brand-new Myth user, I did not.  (Hence my comment, above, which
started with "I only discovered...")

    > This is especially
    > crucial because so many of the submenus have a "General" menu under
    > them, and it's difficult to figure out where you are in the hierarchy
    > if you haven't already memorized it and aren't keeping track of where
    > you're going---

    If you're setting up an application for the first time, you really
    should be keeping track of where you are. If you forget, you can
    always go up a menu to remind yourself.

I was -trying- to keep track of where I was.  It's confusing.
The current behavior makes it more confusing than it has to
be, as is trivially provable by looking at themes which don't
do this.  And if you're setting up an application (especially
one with the complexity of Myth) for the very first time, you've
got plenty of other stuff to keep in your head, in addition to
a Zork-like maze of twisty little menus which mostly all look
the same (and which mostly overlap between two programs that
were -both- run automatically -for- you, and hence before you
know what their names are, what they do, or the fact that there
-are- these two mostly-overlapping bits of configuration UI).

    > (C-2) I find the cursor-based navigation in the installation setup
    > screens confusing.  I know you're trying to avoid depending on the
    > mouse, and I'm a big fan of avoiding mice, but it means that, e.g.,
    > one needs to use the up & down arrows to go -sideways- between Cancel,
    > Back, and Next.

    Think outside of the box. Up and Down change what item is selected.
    Left and Right change the item that is selected.

Yeah, yeah.  Easy to say.  Apparently hard to get right.

    > I seem to get it wrong when navigating these things fairly frequently,
    > despite practice, so there's -something- going on here.

    Practice makes perfect.

Blaming the user is easy.

    > PECULIAR, BUT PROBABLY NOT IMPORTANT:
    >
    > (P-1) I've noticed, on two machines now, that the very first time I do
    > an installation, it claims that every filesystem has not been checked
    > in 49710 days (or so; I may have misremembered the exact number).

    #updatedb

    Set is as a cron job and you never have to worry again.

Huh?  I have -no- idea what you're getting at here.  I was commenting
on a peculiarity of the timebase vs the filesystem, which fortunately
is just an initialization glitch that fixes itself (albeit by making
the user wait through a bunch of unnecessary fsck's of potentially
large filesystems the very first time they're presented with the
program, and thus looks bad and feels annoying).

I have no idea what you're proposing be run as a cron job, or why,
or how it can -possibly- fix the behavior you're commenting on.

    > Whew!  Hope that's been helpful...  Let me know if I can help fix any
    > of this.
    >
    > - - - End - - -

    I think you're making this a whole lot harder than it needs to be. The
    installation steps are pretty well documented and work smoothly
    provided you have standard hardware and follow the directions.

All I can say is (a) even following the directions, such as they are,
this was not as easy -as it could have been-; (b) I'm more experienced
than many in system setup, so I worry about what it's like for those
with less experience; and (c) there are piles of complaints
(especially over on the KnoppMyth forums---I haven't read enough the
archives yet to know about here) from users who've screwed something
up when they tried to install, in ways that could probably be easily
prevented by small bugfixes and attention to the UI.


More information about the mythtv-users mailing list