[mythtv-users] MythTV Installer Usability: An Analysis

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Nov 3 22:39:55 EST 2005

I've spent a while installing and reinstalling MythTV recently.
It's got a lot of usability problems.  Fixing them would help lots
of people.

This analysis is based on KnoppMyth R5A22, but I'm reasonably certain
that only some of them are actually KnoppMyth bugs specifically; many
of them are probably upstream, either in MythTV or in how the basic
Knoppix installer works, which means the former problems will bite
-everyone- who installs MythTV.  But since I'm not exactly sure where
the functionality is split in some cases, I figured I'd just roll
everything together and let the various developers of each piece grab
the relevant bits.  So in particular, my comments below about how
KnoppMyth are doing it are probably really comments about how
mythtv-setup and Knoppix are behaving.  I'm also putting a pointer
into this analysis into the KnoppMyth forum at mysettupbox.tv (see
http://mysettopbox.tv/phpBB2/viewtopic.php?t=6762) so that way
whatever bugs -are- specific to KnoppMyth might get addressed.

[I think the density of Myth-specific (as opposed to Knoppix- or
KnoppMyth-specific) bugs increases towards the end of this message,
but I'm not sure.]

Note also that I wrote the comments below about a week ago, -before-
my run-in with the multiple-tuners problem and the usability issue
with the Capture Card menu.  Since that message was already pretty
long, I'll just say that anyone concerned about mythtv-setup usability
should see http://mythtv.org/pipermail/mythtv-users/2005-November/108145.html.

- - - Begin - - -

I'd like to start by saying that KnoppMyth is really helpful in
getting people rolling, and I appreciate all the work that's gone into
it.  But the installer has got several fairly bad usability bugs, and
it seems that it's slowly getting worse in this regard over time (I'm
comparing this to my memories of partial R5A15, 15.1, and 16
installations.)  These bugs are making people's lives more difficult
than they have to be (mine included), so I'm writing them all down
here in an attempt to get them fixed.  Fortunately, most of them seem,
at least from the outside, like they'd be fast, easy fixes; a couple
of them might require some remodularization or changing the base
Knoppix system, but it's difficult for me to gauge how much work that
might be.

I know that a lot of these bugs are probably not fixable directly in
KnoppMyth, because they're in upstream packages that aren't, strictly
speaking, even modified for inclusion in the ISO.  So I'm also looking
for either advice on where each bug should go, or people who would
like to take up the mantle of submitting/fixing them to do so, since I
don't have a very good idea right now of the modularization of them.
And at least this way they're all in one place and out where people
can think about them.

If KnoppMyth has some sort of Bugzilla or other bug-tracking database
to which I should submit these, please let me know and I'll do so.
(And if breaking them up into one-bug-per-report might make them more
likely to be tracked and fixed, I'll do that, too.  Just let me know.)
I could probably even try to help in fixing some of these, but it's
not obvious to me how much is exactly specific to KnoppMyth and how
much is upstream, since there isn't a published manifest or procedure
for making the ISO.  (This itself is something of a problem; it means
nobody else can respin the ISO and get the same results as the one
they download; it'd be nice if this could be fixed (and more in the
spirit of F/OSS in general) so others could help in debugging.)

All of these problems were found in my (repeated) installations of the
R5A22 ISO, on a 200 GB disk that I've been allowing KnoppMyth to wipe
and repartition each time.  They are -not- upgrades.


(S-1) The installer, by default, picked a 15 GB size for my
ringbuffer, but picked a 12 GB size for the /cache partition in which
it's stored.  This means that, after 5.3 hours of sitting in Watch TV,
the machine blew up.  (The disk thrashed -continuously- and the video
went completely black, while it logged "ENC stream overflow/stealing a
buffer" errors to at least three different logfiles at hundreds of
entries per second; given enough time, this would have filled up the
root partition, too.)

This is a subtle bug---some people might not see it for days or weeks
after installation, and many inexperienced users will have no idea how
to fix it or even what caused it.  Were it not for the suspicious
timing, my own monitoring of the fill rate of the partition, and
finally a post in a forum, it would have taken me a long time indeed
to realize what had happened.

(S-1a) mythtv-setup should check the size of the partition into which
that ringbuffer is going, and absolutely reject any attempt to make
the buffer bigger than the partition (plus maybe some safety factor,

(S-1b) The installer should communicate (with itself!) about how large
it's making that partition, and should set the default ringbuffer size
appropriately, including whatever other slopspace might be required to
make sure that it doesn't overflow.

(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!
It's not clear to me whether the bug is that the entry isn't NULL to
begin with, or whether bashing in the NULL papers over some other bug
elsewhere, but this problem was essentially undiagnosable for days on
the KnoppMyth fora, yet has bitten people using widely different
frontends [including, e.g., R5A15.1 as well as R5A22, and including

I think that part of the problem is that the frontend is mysteriously
defaulting to calling itself "mythtv" instead of the machine name
picked by the user, but only for some operations; thus, the wildcard
NULL is required to handle that.  My backend database currently has
-5- entries for the same machine in it:  mythtv, mythfe1, mf, sbe, and
myth-frontend; it should -really- only have one.  (The latter three
were chosen by me in different contexts; the former two were chosen by
the installer.)

There's more detail about this bug in point (R-3) below, and see
especially http://mysettopbox.tv/phpBB2/viewtopic.php?p=38670#38670
(near the end of the page) and http://mysettopbox.tv/phpBB2/viewtopic.php?t=6572
for examples of before & after database states that fix the problem.

(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.  It probably hasn't tripped up more
people because many are probably using nice shiny new video cards that
do PnP better and support more modes.  But the upshot is that it
picked H: 35.2Khz, V: 86.4Hz and my (fairly new ProView) LCD monitor
instantly choked and said "invalid refresh rate".  [This is itself
very curious, because the defaults in the XF86Config-4 file are
HorizSync 28.0-96.0, VertRefresh 50.0-68.0, and yet it picked a VSync
rate of 86.4Hz---far outside those limits!  I'm not sure how this can
happen, but it did.]

Note that this choked the instant the installer rebooted from the hard
disk, e.g., it worked okay off the CD, but then died as soon as the
machine came back up.  That's an unfortunate time to get stuck...:)

So:  C-Alt-F1'ed and got a text console, spent a while figuring where
the heck an editor was (see R-6 below) given that networking wasn't
initialized yet, fixed /etc/X11/XF86Config-4 to limit HSync to
28-40KHz and VSync to 50-62Hz, and restarted gdm, whereupon X decided
on a VSync of 60Hz and the LCD came back to life.  If you really want
to support spiffy cards at maximum sync rates, it would be nice if the
installer asked (while still in text-only mode!) something like
"should I try the maximally conservative values in case you have an
old card?" so that users could avoid having to edit & restart (and so
that users who may not be particularly expert in XF86Config files have
a hope of this working -at all-; this isn't something you can expect
most people to figure out on their own).  Being conservative in this
way might also save people from accidentally blowing up their TV's if
they've got old TV's that don't have microprocessors in them, and are
configuring with their video plugged into the TV somehow; the
instructions at the mysettopbox site do have this warning, but
why not have the software make it harder to damage the hardware?


(CR-1) The installer emits 3 or 4 serious-looking error messages or
warnings that one should run some program or configure something---and
then instantly scrolls them away before they can be read!  Either a
warning is important, in which case the thing that emits the warning
should -stop- and ask the user to press a key to continue (so they can
read the warning and/or write down the instructions for later use), or
the warning should be suppressed.  The current behavior is beyond
frustrating---it tantalizes the user with what look like problems in
the making, but makes it impossible to know for sure what they -are-,
much less fix them.

(CR-2) I can't find any typescript or other record of the installer's
output after it's done running.  I've tried grepping the filesystem
for likely strings (in particular, those from the dire-seeming
warnings above in C-1), and I haven't been able to turn them up.
Either I didn't get a good-enough look at them before they vanished,
or they're not being preserved.  If they're being preserved, it should
be documented prominently (including at the end of all the output)
where they're going.  If they're not being preserved, they should be;
presumably that would be as simple as running the entire script tee'd
into a file.


(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.
I'm -presuming- that, without timezone information, programs would
still be recorded at the right times (e.g., using UTC), but that all
the actual times presented on-screen in menus (and in the filesystem
if one gets a shell, etc) would be wrong.  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.

(A-2) The above wouldn't be nearly so annoying if it wasn't also the
case that the choice for US East Coast time is -not- the topmost
choice you get if you hit return twice and then type E; instead, you
get East-Indiana, which is a special case because it has its own rules
about daylight savings.  That choice should be -underneath- the common
one, so the state with 5% of the population of the rest of the East
Coast isn't the one you get by default.  Either don't sort alphabetically,
or change the name from East-Indiana to something that sorts -after- East.

(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.  Whatever is asking
for the root password should instead execute in a loop, and keep
retrying until the correct root is entered.  (Or, perhaps, until the
entire installation is known to have finished and not been aborted.
I'm not sure if that's actually possible or desireable, but...)


(R-1) The installer asks me for my zipcode twice, since apparently two
different pieces of software need it.  (The A15/16 installer didn't
ask at all, IIRC, presumably because whatever software needs the
zipcode didn't come preinstalled with those releases.)  It should ask
just once, and cache the result.  It would be -really- nifty if it
asked once, right at the beginning, and used that info to set up my
timezone information---though I'm guessing that this would require
remodularization of the Knoppix setup system.  (There are tables of
zipcode to timezones, so that part's already done.)  It's also not
clear to me what happens to non-US users; can they just skip the
question with no problem?  (And if non-US users are assumed not to be
running KnoppMyth's installer at all, then it shouldn't bother
offering all those non-US timezones, either... :)

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

(R-3) I got the error below even though I supplied a NON-loopback IP
in configuration, which indicates that something is ignoring it.
Also, even though the error claims it's a "timeout", the actual
elapsed time is about 60 milliseconds, which makes me believe it's
probably getting "connection-refused" instead, which has very
different implications for debugging a problem.  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: (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
		error resceduling [sic!] id -1 in ScheduleRecording::signalChange

[UPDATE:  That error is apparently due to a bug in one of the MySQL
fields not getting properly filled in by the installer when the
database is created for the first time; see
http://mysettopbox.tv/phpBB2/viewtopic.php?p=38670#38670 (near the end
of the page) and http://mysettopbox.tv/phpBB2/viewtopic.php?t=6572, at
least; the ISO mastering process apparently did -not- test this case.
So if that's fixed, this error is less likely to be emitted, but the
incorrect "timeout" and the misspelling should still be fixed.]

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.  [Ah!  But I just noticed
that mythtv-setup actually -does- call the field "Master Server IP
address", presumably this should call itself "Master Backend Server IP
address" instead for consistency?].  It also says "the setup program"
but naive users probably won't have any idea -what- setup program it's
talking about.  Presumably it means mythtv-setup; if so, then that's
what the error message should say, instead of making users guess.

I should note also that I saw timeouts making backend connections to 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.  I could probably come up with
more details about this if it was deemed important.  [This is probably
also the same bug above.]

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

(R-5) Running aptitude immediately after the installation claimed
problems stat'ing http://ftp.us.debian.org stable/main Packages,
stable/contrib Packages, and stable/non-free Packages, but it then
immediately managed to load them.  I'm not sure what its problem
was.  The error fixed itself, but I spent a while staring at it before
realizing that.

(R-6) It would be really, really nice if Emacs could be included by
default in the ISO.  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.  (A22 was
already 100meg larger than A16, what's 13% more? :)  In some cases
(e.g., fixing a bad X modeline), the installation isn't even far
enough along to have initialized the network, so either the user has
to bring it up by hand, or use nano, which nobody -I- know uses as a
day-to-day editor.  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.  (And many might not even know to -try-
nano, since it's not the most intuitive of names; 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.  And which, for
that matter, -I- can't, having used Emacs from the days of TOPS-20
before vi even existed.  But maybe we can avoid the religious wars by
having both available.)

This is particularly important since, the -first- time I tried to get
Emacs, I had to do a "u" [not a "U"!] (since the shipped aptitude
databases were so out-of-date (or something) that they didn't even
know Emacs existed if I searched for it with "/"), and then when I
-did- try to fetch it, aptitude tried to reload -hundreds- of packages
because it was defaulting to "recommended packages also" and all of
its packages were out-of-date!  On my next install, I remembered to
uncheck "treat recommended packages as dependencies" in its
Options->Dependencies menu, but it was another annoyance that would
have been avoided if Emacs had been there from the start.  So, please?
Emacs in the ISO?  Pretty please?


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

There is, btw, another reason to prefer G.A.N.T., and that's because
its varous setup submenus include the title of the menu on the screen,
so you can tell, after you select Utilities, that that's where you
are, etc.  It provides a lot more navigational assistance than the six
circles, which don't include this information.  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---and you'd expect any user running the installer to
-not- already have this information committed to memory, or even to
realize that there are several General menus.  (This tripped me up at
least once when I was first installing; I kept thinking, "Wait a
minute, where are the other choices I seem to recall on this screen?")

[This isn't helped by the fact that mythtv-setup and the various
configuration screens in mythfrontend have substantially overlapping
but not identical sets of things they let you configure, so you're
likely to wind up in a situation where you can't remember how to find
some parameter because it's actually configured by the -other- program.
That's undoubtedly a big hairball to unravel, but boy it'd be nice if
it was.]

(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.  I don't have a good idea of how to fix this (since
you still need the left & right keys to change values in fields); is
there some other non-mouse interface that might do this better?  I
seem to get it wrong when navigating these things fairly frequently,
despite practice, so there's -something- going on here.  I'm just not
sure what the least-confusing way is to fix it.  If anyone has a good
example of a better interface, it might be a good example to look
at...  (Maybe just having Cancel/Back/Next be in a vertical stack
instead?  That might require slight changes to the screen layout, but
it'd sure be a whole lot less confusing...  This wasn't helped a bit
by being in the default theme with its very-hard-to-see differences
between selected and unselected choices, of course.)

(C-3) When initially setting up network addresses and the like (before
mythfrontend starts running, I think), the text cursor seems to be a
space, and it starts out in the leftmost position of any given field.
This means that, e.g. if I'm editing an IP address, it looks like the
first character position is a space, until I move the cursor right.
Ideally, this should be some blinking thing, so it's possible to see
what it's over, and it should start out at the right, since that's the
end most likely to need editing (e.g., when setting non-DHCP IP
addresses or the like).  This confused me the first time I saw
it---only for a second until I tried an arrow key, but still, it
initially made me think the network address had somehow lost its first
digit.  (This is especially true because the text fields one sees
during installation -while the CD is in the drive- have a blinking
underscore instead.  That's perfectly readable, but having this change
halfway through installation to something that makes the character
under the cursor -invisible- is problematic.)

(C-4) If you've got Hauppage cards, and you say that to the installer
when you're setting up LIRC, it asks what color the remote is.  Alas,
two of the three choices are "gray" and "silver", and just looking at
a single remote it's pretty much impossible to figure out which one
you have.  I told it "(c) silver" and it immediately barfed and said,
"I don't know how to handle that remote anyway."  It would have been
nicer if the interface at least said that silver wasn't gonna work
-before- making me choose.  As it was, btw, I actually have a "(b)
gray" remote, which I figured out by searching the forums and finding
pictures.  It would be very useful if that particular installer
question either had some text describing the button layout (or
whatever else it takes to tell gray from silver), or if it just had
some URLs, one per choice, which pointed at pictures of the remote.
If it had, I would have chased the URLs and said, "Oh, I have a gray
remote" and not guessed wrong on the first install.  (As it happens,
that didn't cost me anything, since I've had to reinstall since then,
but still, it's a wrong path that's then hard to fix without doing
more research to figure out what value got set where.)

(C-5) You're expected to fill in all the video sources, etc, in the
automatic run of mythtv-setup that runs as part of the installer
running, but then as soon as you actually exit that so the installer
can finish, it complains, e.g., "You've said that the tuner should
start on channel 3, but channel 3 doesn't exist.  Do you want to go
back and fix it?"  Your options are "Yes" and "No, I know what I'm
doing", and the user must claim that he does (whether or not that's
true :) in order to finish the installation---because -then- the
installer downloads the channel assignments and program lineups from
zap2it, at which point channel 3 and all the rest exist, and all is
well.  So there's a timing error on the check here; probably the
lineups should get downloaded first, or the error should say something
like "channel 3 doesn't -seem- to exist, but since I've never
downloaded channel assignments, I won't know until later---would you
like to continue and see if it gets fixed?"  Yeah, I know, that's a
crappy way to phrase it, but really the problem is that things aren't
running in the right order, and that's what should get fixed, if
possible.  [Note that this did -not- happen in A15 or A15.1, IIRC,
so it's a reversion to worse behavior than before---perhaps because
it's doing an error-check it wasn't doing before?  I don't know.]

(C-6) If you run mythtv-setup manually, but you're not root or mythtv
(e.g., because you've just ssh'ed over as the single normal user
created during initialization), you can configure things in the
database just fine.  But when you exit mythtv-setup, it complains
"Cannot create a file /myth/tv/.test - directory is not writable?"
and ditto for /cache/cache/.test.  This is because these directories
are, by default, not owned by the default user (they're owned by
mythtv or by root, not me), and they're not world-writeable.  This
isn't a problem if you know what's going on, but the first time this
happened, of course, I thought there was some spurious error that had
renamed something in the database or the filesystem, so I had to go
check both directories and peer at them before realizing that it was
no doubt a permissions problem.  Either this check shouldn't be run,
or it should be intelligent about knowing that it won't work if the
permissions are wrong, or it should warn the user that it can't finish
the test because the permissions are wrong, or -something- more
intelligent than what it's doing now.


(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).  The
check is quick, but it's peculiar; the time given is 100 years before
the Unix epoch (e.g., it seemed to be about January 1, 1870), and it
makes me believe that this is because the very first install changes
the machine's calendar clock enough (between timezone frobbing and a
readjustment of the machine's clock about half an hour backwards
because both machines had run fast while powered off) such that the
time might have been getting interpreted as a negative number, and
then wrapping somehow to be the epoch minus 100 years.  After I've
-successfully- booted -after- the hard-disk's installation finishes,
this doesn't happen any more; presumably everything's now been fixed.
But I've seen this on 2 (and maybe 3) otherwise identical machines,
and only when installing KnoppMyth and not, e.g., Debian Sarge or
Ubuntu Hoary/Breezy or whatever.

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

- - - End - - -

More information about the mythtv-users mailing list