Posted
by
kdawson
on Tuesday May 11, 2010 @03:49AM
from the record-with-daring-and-whimsey dept.

An anonymous reader writes "After six months of our new accelerated development schedule, MythTV 0.23 is now available. MythTV 0.23 brings a new event system, brand new Python bindings, the beta MythNetvision Internet video plugin, new audio code and surround sound upmixer, several new themes (Arclight and Childish), a greatly improved H.264 decoder, and fixes for analog scanning, among many others. Work towards MythTV 0.24 is in full swing, and has be progressing very well for the last several months. If all goes according to plan, MythTV 0.24 will bring a new MythUI OSD, a nearly rewritten audio subsystem capable of handling 24- and 32-bit audio and up to 8 channels of output, Blu-ray disc and disc structure playback, and various other performance, usability, and flexibility improvements."

Yeah, it's starting to become the classic passive-aggressive "tactic" for open source products to avoid any kind of responsibility. Also, it makes them look unprofessional. All these changes, and all they did was increase minor? X.y.z versioning has a well-defined meaning and is used by lots of other open source products, including commercial. Use it! Not only should it make it easier for you to make a proper roadmap, release quick fix releases and so on, but it also makes it easier for users like me to understand in rough terms what it means to upgrade to a new release. If you need a role model, just look at Apache.

Of course the MythTV "marketing department" is looking for ways to get people to use their product, otherwise they wouldn't be releasing at all and instead simply point to their code repository. And part of having a sensible versioning scheme is to make users understand what it means to upgrade to a new release.

Don't be too hard on Myth TV. After all it's only some guys hobby, that's outgrown itself. If they want to keep it in a state where they can play around with the code, rather than entering the world of professional standards and expectations then that's their business. It does however raise one helluva red flag for people who want / need / expect a product that comes with proper support and can be relied on.

I agree that it's hard to set up. I don't agree that it's hard to keep it running.

You talk about problems when you rebuild the machine, or switch distributions, or upgrade to a new version of MythTV. It's true, those are troublesome. Try to avoid doing those things!

If you want a MythTV system that works reliably, then build a Myth box, get it into a working state, and then *stop tinkering with it*.

Obviously as geeks this is hard for us to do - the temptation to upgrade everything to the latest version is great! But, if you want it to behave like an appliance, I think you need to treat it like an appliance, and leave it alone.

Of course, it would be nice if all the upgrades worked perfectly, but my main point is that I don't think it's fair to say "the overhead of keeping it running is high", if you want to include regular software, OS, and hardware upgrades as part of "keeping it running".

"why can't myth have a "save my database" and "look in this directory for recordings" import , rather than me having to edit my 450MB MySQL database?"

Don't know the last time you tried, but since at least 0.22, it has exactly this using an included python script. Also I'm no fan of MySQL, but I've never had my database corrupt itself yet, and I've done upgrades every 6 months since MythBuntu 8.10. Wonder if there are other causes?

I imagine the reason for using the database to store confs (besides the fact when you already require one for recording metadata, many devs would probably be inclined to stuff everything in there), is to allow easier setup of multiple backend/frontend systems. The master backend contains all the confs, and other nodes can connect to a known port to retrieve them just like the master backend does, rather than maintaining separate code for the master backend to serve text conf files up to connecting nodes.

There is also the fact it makes developing alternative configuration editors easy. Right now you can edit the confs using the native tool on the local machine, using an included webpage/webserver, or external tools like myphpadmin or Microsoft Access. Also Myth has so damn many settings, that for power users and developers doing additions/debugging, using a database is probably easier to manage than a 1000 line long text file.

I imagine MythTV (well, Linux in general) will be ready to hop right on this to take advantage of it so we can finally do away with all those STBs.

Not likely. Media Center gets to have access to CableCard tuners because it supports a compatible DRM format. The DCT cards from ATI (dead), Ceton (coming in a couple weeks), Silicon Dust (coming later this year), etc decrypt the incoming cable signal using the CableCard and then re-wrap the stream in Microsoft's PlayReady DRM. No support for PlayReady, no support for CableCard. Apps like SageTV (on Windows) have found a novel away of getting around this restriction -- rather than accessing the tuner directly, they instruct Media Center to schedule the recording, change live TV channels, etc. It's unlikely this is going to ever work on Linux (while you might get Media Center running in Wine, you'll still be missing the tuner card drivers).

While there's obviously the possibility of reverse engineering the process and breaking the encryption, the fact that ATI's DCT has been available for years now yet there's no such crack doesn't give much confidence that new tuners arriving on the scene will change that.