[mythtv-users] Simultaneous recordings fail spectacularly [SOLVED!]

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Nov 3 21:48:08 EST 2005


SOLVED!  (And man, somebody ain't gonna like -this-... :)

It turns out I just tried installing KnoppMyth R5A16 as a quick test,
before trying out Ubuntu Breezy as a Myth distro, since I was about
to give up on R5A22.  And I hit exactly the same problem, which was...
remarkable, considering how different the two releases are.  So the
common failure mode in this scenario is....

Consider:  I've spent 30+ years in the field---in compiler design,
artificial intelligence, hardware hacking, software agents, computer
security, cryptography, and even (wait for it...) user interface
usability testing.  And yet I -still- managed to assign every single
one of my tuners to the same Unix device---and failed to discover this
fact for a solid -week-, despite half a dozen reinstalls.

How could this happen?  Because mythtv-setup is the absolute -mother-
of all usability screwups.  And because this particular error has NO
warnings and masquerades as BROKEN HARDWARE.  So this poor usability
just cost me about a -week- of debugging time; see below for why this
was such a bear.  Sure, if I hadn't been fairly new to Myth, it might
have gone faster---but measuring usability by -expert- users is the
first fundamental mistake of evaluating usability in the first place.
(The Ubuntu usability team would absolutely wipe the floor with this
design, and we need to fix it.  They've set a high standard for
usability in configuration; it would be extremely nice if we tried
to follow suit.  And I'll help, assuming I haven't pissed off every
current developer in a hundred kilometers once you read the analysis
below.)

[And before the ivtv people write this off as "not my department",
wouldn't it be nice if ivtv could somehow notice, e.g., that it's
being asked to set the same card to incompatible settings at the same
time?  Or that cards are sharing devnumbers?  Or some other way of
screaming bloody murder if the higher-level interface looks like it's
doing something stupid?  I don't know the details of the ivtv API, so
I can't tell if this sort of information is just fundamentally
unknowable at the ivtv level and I'm asking for the impossible.
But if it -is- possible to have ivtv log errors in this case, or do
something else to aid in debuggability, boy, it'd sure be nice if it
did.  Because I saw -nothing- in any logs to indicate that multiple
entities were all fighting over the same card hardware.]

So---let's go to the Capture Cards menu for a moment, shall we?
There are a number of really, really serious problems with this menu:

(a) The "video device" field does NOT automatically increment as you
    assign cards!  Nor does it give you any idea how many have been
    assigned, or are yet to be assigned.  If you have several, you
    have to keep careful notes lest you accidentally lose track	and
    assign the same device to more than one card.
(b) If you EDIT that field, using Rubout and by typing in a new
    number, and then hit Return to activate the Finish button, YOUR
    CHANGES ARE SILENTLY THROWN AWAY.  Surprise!  Guess how often
    -that- happened before I caught on?
(c) This violates a really fundamental principle of UI design:
    If editing the field cannot change its contents, it should
    NOT be editable in the first place!
(d) Instead, you must SELECT a replacement with the left/right arrows.
    Is this obvious unless you've been burned?  Absolutely not.  And
    you have a strong incentive to -not- do so, because---
(e) These replacements are in ASCII order, not numeric order!
    So the very next thing you get after video1 is---yeah, video10.
    Brilliant.  It's a lot faster to type "Rubout 2" than to scroll
    through the whole list.  But if you type....  well, see (b).
(f) There is NO WARNING WHATSOEVER if you assign more than one
    hardware card to the same Unix device.  None.  Nowhere.  (Despite
    all -kinds- of spurious, -wrong- warnings in recent builds about
    nonexistent channels---which should -not- be emitted before the
    listing is sucked down---but I digress.)  Is there -any- reason
    why one would -ever- do this?  And even if there is, one might
    argue that the menu should check EVERY time you hit the Finish
    button and pop up a BIG FAT WARNING saying "Hey!  You've just
    assigned two cards to /dev/video0.  This is almost certainly a
    serious mistake; are you absolutely sure you want to do this?"
(g) Because there are both "video0" and "tuner0" fields all over the
    place, and because each -card- wants its video0 selected even if
    the Unix devices increment, it's really, really easy to either
    misunderstand or misread the page you wind up on after you hit
    Finish.  I consistently misread that as "tuner0" and/or "video0
    on the card" and not /dev/video0.  For a week.
(h) Failure to assign every card uniquely leads to FAILURES THAT LOOK
    LIKE BROKEN HARDWARE and which CANNOT BE FIXED without powering
    down for at least a minute.  See my previous mail about channel 2
    (only!) losing its audio in these circumstances without a hard
    powerdown; this lead me to several days of thinking that audio
    didn't work, either out through the 350 or in from the 250's, and
    then more headscratching when I realized that audio was sometimes
    there and sometimes not.  (And let's also not forget that getting
    this wrong causes the hard disk to be NAILED ON for the entire
    duration of a simultaneous recording; this -also- looks like some
    sort of bizarre hardware bug and/or IDE-channel screwage, etc etc,
    hence further muddling the debugging.  I presume that this is what
    happens when two drivers fight over the same set of registers on
    the card, but c'mon---those drivers should never have allowed the
    user to -put- them in that situation to begin with.)
(i) Attempting to fix this (once discovered) by changing those device
    numbers in mythtv-setup does NOT fix the state of the machine
    without rebooting it.  (I tried.)  Apparently the cards stay
    misinitialized.  But as soon as the machine came up, it asked me
    for the root password and jumped directly into mythtv-setup
    without telling me why.  Since I had no idea -what- weird state it
    must be in, and since I'd just installed A16, I just hit the reset
    button, had the installer wipe the disk, and started over---I
    didn't want to waste time winding up in yet -another- ill-defined
    state just to see if I'd fixed the problem.  Chalk up another
    usability failure---if something was so screwed up that the
    installer felt it had to run, it should have told me, instead of
    just mysteriously prompting for the root password and failing to
    start mythfrontend.
(j) If we really wanted to be nice, the installer would take a look at
    the machine configuration and say something like, "Hey!  I notice
    you've got a bunch of cards.  Would you like to assign them all
    SEQUENTIAL DEVICE NUMBERS and select the same INPUT and VIDEO
    SOURCE for EACH of them, automatically?"  That would save a -ton-
    of error-prone hand-editing, and leave the user with a basic,
    usable configuration immediately, which he could then alter
    incrementally to, e.g., assign a composite input to one of the
    cards, or say that one of the cards is getting its program data
    from a different source, or whatever.  But the -last- thing we
    should be doing is -requiring- the user to pick DEVICE NUMBERS,
    for god's sake.  From a user's point of view, they're all
    identical, and the -only- thing that matters as far as the machine
    is concerned is that they be unique.  We should let users
    -inspect- those numbers (in case they need to debug a problem),
    but we absolutely should not -require- that users -supply- them,
    given the consequences of getting it wrong.

In short, the fact that this form works the way it does (especially
including having to pick device numbers) is a classic case of the
developers being waaaay too close to the problem to understand the
mindset of a first-time user.  They just don't see the pitfalls.
(And let's face it---everybody who is -in- this menu is there as a
first-time user, and often it's the -last- time they see it---assuming
that they don't screw it up.)  And so developers don't understand why
users -do- screw up---and then they blame those users for being
pinheaded.  We've all seen this.  Let's not contribute to the problem.

And all of this, of course, is built upon the horrible, horrible
usability of the mouseless form-filling interface, or whatever you
call it.  I know that using the mouse is asking for trouble.  But the
way it's currently done is just awful.  Why is it so bad?
(a) It's totally undocumented.  What key does what?  Who knows?  The
    very first time I was presented with this puzzle, I spent several
    minutes trying keys at random, trying to figure out how to
    navigate, change fields, etc.
(b) I only -just- discovered that Tab will move from one field to a
    later field.  But what does Alt-Tab do?  It pops up an xterm, for
    god's sake?  WTF?  Can I move backwards without uparrow?  Who
    knows?
(c) You should NEVER have arrows that conflict with the spatial layout
    of the form.  It's not -too- bad in the Capture Card menu, because
    it's only got 3 fields, and they're stacked vertically.  But just
    -try- to use the Manual Scheduling form.  Go ahead.  I dare you.
    Wanna move right?  Hit the DOWN arrow!  Wanna record for fewer
    minutes?  Hit the LEFT arrow!  I swear, every time I use this form
    (and I've been using it quite a lot in the last few days), I
    invariably wind up careening off SIDEWAYS, always moving left when
    I meant to change a value, or bashing a field value when I meant
    to go to the next one.  Why?  Because the fields are all laid out
    HORIZONTALLY, hence REVERSING the meaning of the arrow keys.
    Whenever I'm trying to use this form, my face turns red, steam
    shoots out of my ears, and I curse the day its designer ever
    walked the earth.
(d) This is not an unsolved problem.  There are plenty of better
    keybindings for this sort of form-filling, and many of them were
    figured out in the days of EBCDIC and 3270 terminals.  For all I
    know, there are -already- reasonable navigational bindings in this
    menu---but since they're undocumented, I have no idea if that's true.
(e) Why do the fields allow typein, but then silently throw it away?
    Maliciousness?  Latent schizophrenia in the implementor?  Who knows?
(f) The horribleness of this interface is another symptom of usage by
    developers without listening to end-users.  Developers and power
    users, who've spent weeks in this interface, don't notice.
    They've adapted.  But I've only spent a single week (ugh!)
    in this interface, and it still pisses me off every time.

We can do better.  I'm sure we can.  And the first step do doing
better is to admit that we have a problem.

Thanks for listening.

P.S.  The news isn't -all- bad.  The week I spent debugging got me to
these lists in the first place (since support for the more obscure
bugs on the KnoppMyth forum wasn't too hot), hence overcoming my fear
of losing enormous amounts of time to the vast waterfall of traffic
that is (especially) mythtv-users.  And it made me aware that people
-have- been having success using Ubuntu Breezy as a base distro for
Myth, which means I'll probably punt my KnoppMyth installation and
redo it for Breezy so it matches all the other hardware around here.
But geez, there were better ways, and better times, for me to have had
to do all that, and especially better reasons than fighting a usability 
nightmare that's apparently persisted unchanged for some years now.
Let's -please- get it fixed.  I'll help.  (Maybe I already have.)


More information about the mythtv-users mailing list