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. SHOWSTOPPERS: (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, too). (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 OSX.] 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? CRITICAL: (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. 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. 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...) ROUGH EDGES: (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: 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 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 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. 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? 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. 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. 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). 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 - - -
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
