Boston Linux Meeting Wed, July 15, 2009 Another Look at MythTV and MythDora

[Jarod Wilson]

I actually did have these topics in my notes to talk about last night,  
but with me being late and the volume of questions (which isn't a bad  
thing, I like interactive), I just didn't get around to them, so I'll  
try to at least briefly address them here...


On Jul 15, 2009, at 2:46 AM, Tom Metro wrote:
...
> How about talking a bit about the MythTV support community. For  
> example,
> there's lots of good info on the users mailing list, but it is nearly
> impossible to actually follow it on a regular basis. I imagine this
> impacts the ability of knowledgeable users to respond to questions. I
> find there's a good chance that postings will go without response.
> (There seems to be a sweet spot for the size of open source  
> communities.
> Too small and there aren't enough contributors. Too large, and there's
> too much noise, unless you can subdivide.)

So like many open-source projects, MythTV's support community is  
entirely made up of people who provide support out of the goodness of  
their hearts (or something). I'm not aware of anyone who actually get  
paid to sit on the mailing lists or irc channels to provide support.  
Such being the case... It can sometimes take a while to get an answer  
for any given question, and there's a chance some of the answers you  
get are going to be *WRONG*, but there are a fair number of folks that  
frequently provide very good advice when they've got time to reply.

I used to be one of them myself, but due to list volume, wife and  
kids, work, etc., I more or less completely dropped off the mythtv- 
users mailing list for the better part of about two years. I've  
recently started reading and replying on the list again though. I just  
have to apply fairly strict internal filters -- I try to only reply in  
threads where I *know* the answer for sure, or if its about something  
Fedora-related or LIRC-related (I'm doing a lot of LIRC driver work  
these days). Having a good mobile email client actually helps  
tremendously for keeping up with the list, because I can quickly weed- 
whack through a bunch of uninteresting topic emails on my phone, leave  
behind the interesting ones, and write proper replies when I get  
around to it. But it does take some effort to keep up.

For the casual follower, Gossamer Threads' searchable indexing of the  
MythTV mailing lists helps out tremendously:

http://www.gossamer-threads.com/lists/mythtv/

Much easier to input a search term and look over the results than to  
wade through a mailman archive, particularly for a new user who likely  
doesn't have several years of the list archived, indexed and  
searchable in their mail client (hell, I don't have that either, I use  
the delete button heavily, I only keep around emails that have  
interesting (to me) tidbits in them).

There's also a #mythtv-users IRC channel on freenode.net, which can  
occasionally be a good source of help, but its also pretty high noise.  
The #mythtv channel is much lower noise, but its for development- 
related discussion only, and you will be referred to #mythtv-users if  
you ask non-development questions there. Other channels potentially of  
use are #lirc, if you need help with anything remote control related,  
#linuxtv and/or #v4l if you need help with a video capture device.  
During business hours, I can generally be found in #mythtv, #lirc and  
#linuxtv, IRC nick j-rod, and if need be, can be dragged kicking and  
screaming over to #mythtv-users. :) (I'm also in a few other Fedora- 
specific channels).

> Related to support, it's also worth noting that MythTV devs have a
> policy of rejecting bug reports that don't come with patches. It  
> seems a
> lot of valuable information gets tossed out in the guise of keeping  
> the
> bug database small.

Yeah, that's... A touch annoying, not really a policy that I agree  
with, but I do understand on some level. All the MythTV devs have day  
jobs that typically don't revolve around MythTV, so most development  
is doing in their spare time, and generally, only on things of  
interest. As long as it works for THEM, they're happy. If it happens  
to work for other people, good for them. If not, well, if they want it  
to, they have to make it work -- so bug reports without at least an  
attempt at a solution quickly get dismissed. I think some new bug  
states were recently added though, so that bugs could be put into  
NEEDINFO or NEEDPATCH or some such, which keeps the bugs out of  
developers' bug queries, but makes the reporter feel perhaps slightly  
less, well, slighted...

> As this is the third or forth talk we've had on MythTV, how about
> supplementing the 101 topics with a few 201 topics, such as:
>
> As a MythTV contributor, how do you manage the problem of keeping a
> stable, usable system while doing development?

Most of the destabilizing development work happens in a branch, then  
only gets merged to svn trunk once its deemed at least stable enough  
for all developers to run.

> Do you run the SVN
> version  everywhere, and find it stable enough?

I do run the svn trunk version everywhere, and yes, its plenty stable  
enough. I'll typically run the latest release for a month or three  
after release, then start tracking svn trunk again. I've been on 0.22- 
to-be svn trunk builds for at least six months now, probably closer to  
nine or 10.

> Do you have dedicated development hardware?

I do have some systems I use for testing, but amusingly, I'm actually  
using them to test 0.21 builds, and I run 0.22 on my "production"  
systems.

Note that I don't actually do a whole lot of MythTV development these  
days though -- i.e., not a whole lot of digging in the MythTV code  
base. Most of my work is lower-level of late, on the LIRC drivers,  
video capture device drivers, some FireWire driver and library work,  
etc. I don't think I've committed more than a handful of changesets to  
0.22 development.

> Do you switch back and forth? (The tight coupling
> between the client and server makes it difficult to mix client/server
> versions.)

Sort of. Once I go svn trunk on my production setup, it pretty much  
stays that way. My test systems routinely get reinstalled, change  
MythTV versions back and forth, etc., but I generally don't bother  
trying to preserve any of the setup when going from say svn trunk back  
to the latest released version.

> As a developer, how do you feel about the architecture of MythTV. I've
> never studied the low-level pieces, but the larger components seem  
> to be
> fit together poorly.

I'm generally quite happy with it, actually, and don't find things fit  
together poorly at all. I've never really dug into the low-level guts  
of MythTV either though. My MythTV development work has been more  
'find itch, scratch, move on', and like I said, I'm actually working  
more lower-level in the operating system stack outside of MythTV these  
days.

> (Fairly obvious that the code evolved as a
> succession of hacks, with not quite enough refactoring.)

Well, it started out only supporting analog capture cards, doing  
software-based encoding, and then exploded from there -- hardware  
encoders added one new twist, hardware decoders another, then came  
digital capture cards, firewire support, miscellaneous other device  
support and so on, with code coming in from all over the globe.  
There's been *some* work done to refactor the code here and there,  
particularly while converting from qt3 to qt4, but as the saying goes,  
if it ain't broke, don't fix it, and for most developers, it ain't  
broke, and for many, there's not a lot of joy to be had in code  
refactoring.

> For example,
> there's the tight client-server coupling I mentioned earlier. Not only
> does the back-end have to talk the same protocol version, but the  
> schema
> has to match as well.

Well, there are some good reasons for it... But the major reason is  
this: maintaining backwards compatibility doesn't interest most  
developers. It requires doing work that nobody wants to do. So the  
simple solution is to require that the frontend and backend always  
speak the same protocol version and have an appropriate schema  
version. This portion could probably be better architected, and there  
are certainly ways to keep backwards-compat, which would be nice for  
end-users, but again, the plain and simple fact is that its just not  
interesting enough for any (current) developers to implement and/or  
maintain.

> By most standards it's considered a major layer
> violation to have the client talk directly to the database, bypassing
> the back-end server.

Yeah, that's on the list of things that must die, and be done entirely  
by the frontend talking to the backend over mythtv's protocol, no more  
direct database access. I forget if someone is actually working on it,  
or if its just on the nebulous "hey, we should do this some day" list...


> There are also large sections of MythTV that should be far more
> "plastic" than they are, which slows development and adds barriers to
> contributions. Almost the entire system is implemented in C, but the  
> UI,
> and things like commercial break analysis ought to be implemented with
> an interpreted language and be more capable of end-user modification.

The UI could certainly stand to be done in something other than C (Qt/C 
++, actually). Commflagging, I dunno, you might lose out considerably  
on performance moving to an interpreted language.

What *would* be nice is to see the mythtv protocol fully documented  
(maybe it is, and I just haven't looked...), so that people *could*  
easily write replacement frontends in the language of their choosing.  
I know there's at least one such effort out there, using python and  
clutter, but I dunno how functional it is or what version of MythTV it  
works with or, well, anything about it, other than its project page is  
here:

http://code.google.com/p/gloss-mc/

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org