MythTV vs. SageTV Smackdown: Part II

In my prior article, I discussed several topics to consider prior to using either HTPC software package.  This included features, cost, flexible topology, and OS friendliness.  Today, we will cover some of the differences that are found once the software is installed.

DOCUMENTATION/SUPPORT:

Nothing can be more frustrating than to find yourself beating your head
against the wall due to a problem only to discover that you must be the
first person in existence to ever experience that issue.  The docs are
silent, Google doesn’t turn up any hits, and tech support is clueless. 
So much for that peaceful evening of popcorn and flicks.

Fortunately, both platforms provide a wealth of knowledge in the
form of wiki’s, mailing lists, forums, HowTos, FAQs, and in the case of
SageTV, official techs who will reply within 72 hours of your request
for support.  It is comforting to know that help is out there should you need it.  Here is
a brief list for each platform:

COMMUNITY:

No one wants to be the only one using a particular application, and
it’s no different in the land of HTPCs.  As funny as it may sound,
comradery plays an important factor.  It’s comforting to read up on the
progress, issues, or plugins that others have found.  Thankfully, both
software packages have a rich community experience which is actually
encouraged by the developer.  It stands to reason since it can only
benefit them by fostering the spread of knowledge in the product and by
providing a sense of ownership in the ultimate success of the chosen
platform.

Creating hooks and generating a well documented API allows those who
are handy programmers to extend the feature set or look of the
product.  The MythTV camp is probably the most extreme case since the
entire application source code is available for download
if the user ever has a hankering to change something.  SageTV isn’t
quite as cavalier with it’s source, but there are still plenty of ways
to mod the software through their documented API.

Grassroots communities also serve as an excellent marketing tool to
promote their product.  HTPC geeks tend not to buy into the typical
marketing spiel, but instead choose to place their trust in a friend’s
candid opinion on the matter.  If things go south after the purchase,
that same friend is usually there to help debug the problem.

INITIAL SETUP:

So, you’ve got the hardware assembled and powered up, the OS installed and now it’s time to install the HTPC software.  How hard could it be right?  In my experience, this along with codec fiddling is one of the most frustrating tasks when dealing with a HTPC.  Due to all the possible user scenarios (we all have our preferences you know), HTPC software makers have had to include a mountain of configuration options and wizards.  The trick is how to include that flexibility without making the software look like the cockpit of a 747.

Sage has an abundance of wizards and fairly well documented menu options.  For those that are daring, you can even hand tweak the text config file.  For those of you with QAM, I feel for you.  I really do.  Why does the simple process of assigning a QAM channel to a program guide listing have to be so convoluted?  I’m sure it has something to do with how things were done in the past, but that really is no excuse.  It should not take multiple applications and several hoops to perform this process.  It should be a simple matter of select this QAM channel, select that guide listing, and press "Link".

While it’s not as streamlined, Myth has improved greatly in the past couple years in the initial setup area.  QAM setup is MUCH easier.  There really is no easy way of automatically assigning QAM channels to listing data since cable providers are free to bounce them around like basketballs, so this is probably as good as it can get.  The down side is the configuration data is not stored in a plain text file, but rather in a mySQL database, so those wanting to tinker behind the scenes will need a mySQL client.

RELEASE CYCLE:

This isn’t something that is typically thought about when planning a
HTPC purchase.  Just how often is this software package going to be
upgraded?  Is there a long development cycle which hopefully generates
stable code, but may fall behind in features?  Or, maybe the releases
are frequent incorporating new features and bug fixes, but also
probably creating more issues in the process.  I suspect that each user
has their own preference of which method is right for them. 
Thankfully, both packages offer their users an option.  Choosing the
beta route offers quick access to new features and also provides an
opportunity to "give back" to the community by helping to squash bugs. 
If you aren’t feeling quite so daring (or your WAF just can’t tolerate
any more hits), then you can instead stick with the production release
code.

I have found the Sage beta code to be quite solid for the most
part.  In one case, beta code was necessary for me to overcome a
limitation in the QAM tuning functionality.  After a few trips to the
forums and a couple hours of fiddling, I was up and running without
further issue.

With Myth, the beta branch can be a hairy experience.  Due to the
open source nature of the software, it is possible to grab the code at
any point in it’s development cycle.  While this provides unprecedented
access to the code, it also means that you might be grabbing something
that does not even compile properly.  I have opted to run this when a
new production release was only a month or so away, because the code
modifications had settled down.  After a release is pushed out, the
beta code can become quite distorted and broken as major changes are
made.  Any user wanting to use the beta code should monitor the dev mailing list to keep abreast of these abrupt code breaks.

WAF:

Ah the ubiquitous Wife Acceptance Factor.  This one is a bit difficult to measure due to everyone having wives or spouses with different technical aptitudes.  I can however compare my wife’s experience with both systems, but bear in mind she used Myth for several years before shifting to Sage three months ago, so she may be a bit biased.

First and foremost, she does not like the Sage UI.  She finds there to be way too many menu options when all she wants to do is watch a recorded program or listen to a song.  "Why do I have to click Watch TV, then Recordings, then scroll to the correct show, click to select the show, and then click play?" is a line i hear often.

I find two things troubling with this statement.  First, she’s right.  There are too many button presses required to do one of the primary features of the software; play a TV show.  Second, why is it that the button which works to make selections in the UI, "OK", doesn’t immediately play the show when you scroll to it?  It instead chooses to show detailed program information.  If you wish to play the file directly from the recordings listing, you have to remember to press "Play".  My wife finds this inconsistency to be very frustrating.  In my mind, clicking "OK" or "Play"  should play the show while pressing "Info" should bring up detailed info.

Oh, and don’t get her started on trying to play music on either platform.  Why is it so difficult for UI designers to create an interface where playing music doesn’t require a Doctorate?

CONCLUSION:

A lot of what we covered today is less technical in detail, but no less important in the design decision.  In fact, it’s topics like these that tend to be the long term issues that come up in daily use.  Having a robust documentation system or community for support can be invaluable.  Also, having a system which is intuitive to operate makes a spouse (and therefor you) happy.  I’m sure there are other points which I have missed, so please comment in the forums by following the link below.