[mythtv-users] MythTV Installer Usability: An Analysis

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

    Date: Fri, 4 Nov 2005 09:55:53 -0500
    From: Dewey Smolka <dsmolka at gmail.com>

	       Also you're going a bit scattershot with issues that are
    specific to MythTV, specific to Knoppmyth, specific to Knoppix-Debian,
    and specific to your hardware without really thinking about them in
    context.

Yeah, I know, and I apologized for that in advance.  OTOH, I've been a
little surprised that, e.g., Cecil has claimed as "his" bugs (e.g., in
KnoppMyth) certain things that I would have sworn were upstream in
either Knoppix or Myth, so I'm not sure what to think.  I'm hoping
that the relevant maintainers will at least consider the pieces
relevant to their projects.  (Though if some of these are upstream
Knoppix issues, those people probably haven't even seen any of this
discussion.  OTOH, those are probably the irritating-but-nonfatal
variety anyway, like the annoying timezone stuff.)

    This still ignores the point that you're not using your appliance in
    the recommended fashion. You could also complain that leaving your
    coffee machine on overnight causes the caraffe to become uncleanable
    and ruined. It may be true, but that is not how you're supposed to use
    it.

It's rarely productive---though an entertaining spectacle---to have an
analogy war, but I'll dive in anyway even though I know it's probably
a bad idea:

I'd argue that a more-correct analogy is, "We know how to design this
coffee maker so that it will turn off when the carafe is empty, and it
wouldn't cost any more to produce nor make the device less desireable
from the user's perspective, but we won't bother to implement it,
because you're not supposed to be leaving it unattended in the first
place---even by accident---and so it's your own damned fault."

Let's please not punish the users.  Please?

This is also likely to be an easy, quick fix, so why are we spending
this much effort arguing about it?  Sure, there are several independent
things to be changed (fix the installer not to guess wrong; fix the UI
not to allow bad choices; fix the actual live-tv recorder not to
overfill the disk), but each one seems easy, and the end result is
a much more robust system.

[Btw, I appreciate your later comments on how much live TV differs
from actual recording; that's totally nonobvious to someone who hasn't
looked at the code, and very much not what I would have suspected,
since it's not the design decision -I- would have made...  I was
thinking last night that one way around the "slow delete" issues would
be to divvy up the recordings into, say, 100MB chunks, and then delete
them -in the background- when necessary.  But that's probably moot if
message about ticket #340 means that live TV will be totally redone
anyway.]

    >     <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:
    >     > <snip>
    >
    >     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 this is the case, then this is something specific to Knoppmyth, not
    MythTV.

I really have no idea; I'll defer to those who understand the codebase
better than I.  I'll point out that one of the contributors to the
thread made the (uncited) assertion that "recent builds of mythfrontend" 
had the bug, and it's my guess that a mythfrontend bug is in Myth and
not Knoppix, but really, I don't know.	I'd be happy to contribute
info on the symptoms, workaround, etc etc, if it would help to fix the
bug; all I need is someone who says they're willing to be responsible
for fixing it.

	    You may have also noted that R5A22 is based on an SVN build,
    and as such is not only Alpha (the A), but outside of the stable .18.1
    MythTV release. Please see Isaac's comments on this.

Yeah, I saw those comments yesterday, and man, I'm sure not happy
about the situation.  It's one of the reasons I'm considering
rebuilding my Myth based on Ubuntu Breezy, right now, even though
the setup is -really- already needed for the projects here it's slated
for, just so I'm not in a weird and untenable later situation wrt
protocol versions and other incompatibilities.  (I'd rather trade some
additional delay now for fewer surprises later when more people are
depending on it.)

							 Either way, this
    isn't really the place to complain about issues specific to Knoppmyth,
    since not everyone here uses it.

Absolutely agreed.  My problem was that it's not clear (to me) exactly
where some of the problems lie.

    <snip>
    >     > (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.  [...]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).

    There's no doubt that it's easier to set up a FE than a SBE. But at
    the same time, I'd recommend against using the PVR 350's out -- you're
    making the setup more complicated than it needs to be, plus you're
    asking for headaches when it comes to getting X, MPEG-4 playback, and
    other FE features running properly on the 350. As I suggested, you're
    much better off using a cheap nvidia card for TV-out through S-vid,
    which would also mean that you can put the 350 in the BE and not worry
    about a SBE.

I'm not disagreeing with you, although I've got some questions.  First
off, we'll still be in an MBE/SBE situation, because when the hardware
was acquired (actually quite a long time ago; it's a long story),
dual-tuner cards weren't well-supported, and there is (so far) at
least one more tuner than slots in a 5-slot PCI mobo.  (Soon there
may be an HD capture as well, so add yet another slot.)

At the time when the hardware got acquired, it wasn't clear to me that
the situation wrt MPEG-4 playback was stable---can you recommend any
particular MPEG-4 hardware decoders that work well with Myth?  It'd be
a pity to have wasted the extra money buying a 350 when a 250 would
have sufficed (given an MPEG-4 decoder elsewhere, that is), but it may
well be worth it if it enables transcoding the MPEG-2 from the
250/350's into something that takes up significantly less space;
this project will be generating a very significant archive of video.
I have no desire at all to burn DVD-compatible video, so it doesn't
matter a bit to me whether the eventual archived video is MPEG-2 or
MPEG-4, so long as the process is stable, quick enough to keep up
with the incoming video (not all tuners 24x7, but I'd estimate at
least an average of -1- tuner 24x7's-worth of video), and I can
actually -see- the result -as- video on something.

My big worry is stability and complexity---I see a lot of traffic
about nv versus nvidia drivers, the possibility of problems with
VIA-based motherboards (these are MSI K7N2 Delta-L's, which I
-believe- are VIA based, and at least 1.5 years old), and with
whether, e.g., commercial-suppression works well in the face of
transcoding, etc etc.  It's a fair bit of complexity and lore to
assimilate on top of this -other- thing here... :)  But if you're
confident (and if someone has good recommendations for) MPEG-4 capable
playback hardware, then it's an idea I will definitely consider.
[Other constraint---any card with an audible fan is out of the
running.  I dunno if these cards typically have fans, but I know
that a lot of high-end video cards do.]

(I say "MPEG-4 hardware" because I'm leery of loading up an Athlon
2800+ with all of MPEG-4 software playback, at least one running
MPEG-2 capture card (the 350), possible transcoding and/or
ad-skipping, -and- maybe a future HD capture card.  The BE machine's
going to have 5 250's; while they won't all run 24x7, there's a limit
to how much computation I probably want to do -there-, too.  Maybe I'm
being too conservative in what the hardware is capable of; I don't
have the operational experience to know for sure.)

The 350 solution will certainly work, and it's simpler.  But I'd be
psyched if I could instead use MPEG-4 to save space, assuming that the
transcoding operation and the resulting stability of the FE that plays
the video are good.  I just haven't researched that angle at all yet.

(Opinions and advice very much solicited!)

    Neither MythTV nor Knoppmyth is responsible for an incompatible video
    card.

Yeah, that's sorta what I figured (it's Knoppix's issue), though it
wasn't clear to me if KnoppMyth could tweak this in any way.

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

    Again, this issue is with Knoppmyth and would be better taken up with
    Cecil and the other Knoppmyth developers.

Okay.  I don't know who owns this bug, but I'm going to just assume
that -somebody- is going to step up and claim it, and maybe bounce it
back to Myth if it's not KP-specific.

    I think you have a fundamental misundertanding of what Knoppmyth is
    supposed to be. It is a self-contained package that includes OS,
    MythTV, and all the dependencies. The idea is to simplify the setup
    and eliminate the need to dowload various packages and kernel modules.

Right.

    It is NOT, however, a fool-proof installation for newbies. Ironically
    (because it appears more complicated), it is far more effective, and
    easier, for someone with little Linux experience to install MythTV by
    following Jarod Wilson's excellent guide or one of the other
    step-by-step guides than to do it with Knoppmyth.

I might rephrase that to say "little Myth experience", actually, though
I'm certainly beginning to get that impression, and I think I'd trust
the result (once I get it installed) much more.  That's sure not how
it seems to be advertised, though.

One of the problems with, e.g., Wilson's guide and all the other stuff
out there is the sheer size of the "chaff" problem---a project such as
Myth that touches so much random hardware, and is as old as Myth is,
has a great deal of lore and cargo-cult workarounds for things which
probably aren't quite true in modern builds---but it's -very-
difficult to figure that out if you don't already know Myth well.
This is made worse by all the various distros it might be installed
on; the eventual interaction matrix is huge.

By installing KnoppMyth, I was hoping to (a) sidestep a lot of that
complexity, and (b) have a large-enough critical mass of users who
were all running the same code that it was likely that a problem I saw
would have already been seen by someone else.  (It's for damned sure
that the video0 problem I had would have been -much- more difficult to
debug if I couldn't have trivially flipflopped between A16 and A22,
for example---I would have been much quicker to conclude that I'd
misbuilt a package and much slower to realize it was a case of pilot
error induced by an awful UI.)

    This is not to criticize the excellent work that Cecil has done, quite
    the contrary. But all the same, Knoppmyth is simplified but not
    simple. If a person doesn't understand the various components of
    MythTV and how they all fit together then a Knoppmyth install can be a
    frustrating experience.

I agree, but I'd also add this:  Of the two major problems I had (no
BE/FE communication due to SQL database bug, and totally screwed up
devnumber/card assignments, each of which cost me about 5 days), the
first was just a bug (and could have hit any distro), and the second
is present in -all- distros, because it's built into the way
mythtv-setup is designed.

Without the bug and the UI deficiency, installing KnoppMyth would have
been totally painless, and I'd probably never have even gotten here.

    At this point, it takes me only an hour or two to set up a Knoppmyth
    machine, while one based on Fedora takes the better part of a day. But
    my first attempt at MythTV, through Knoppmyth, took me more than a
    week to get running, and several weeks before I had it running how I
    wanted.

I can believe that, based on my experience so far.

    In switching my MBE to Fedora, I learned what components go where,
    what needs to talk to what and how, and all the steps that are
    necessary between downloading an iso and recording television. Once a
    person understands this, it is much easier to pinpoint where things go
    wrong, and thus it becomes much easier (and faster) to install
    Knoppmyth.

Yup.  Well, my next step is to start over on Ubuntu Breezy, probably.

Thanks!