[mythtv] mythui

Michael T. Dean mtdean at thirdcontact.com
Mon Feb 4 18:52:52 UTC 2008

On 02/04/2008 09:43 AM, Bert Haverkamp wrote:
> 2008/2/4, Steve Daniels <steve.p.daniels at googlemail.com>:
>> On 04/02/2008, Bert Haverkamp <bert at bertenselena.net> wrote:
>>> How easy is it to put 0.20 and 0.21 side by side on one machine?
>> Go on, take the plunge and go trunk, I double dare you ;-)
> Sounds encouraging:-) Thanks, I will consider it!
>  But please explain: What is the reason for trunk if it can't get
> unstable occationally? Or are all extensions added without any bugs? I
> would asume it goes through les stable periods occationally.
> How often will my wife hate me for upgrading a trunk version of mythtv???

It depends on how well you do keeping up with the -dev and -commits 
lists and whether you make appropriate decisions about when to update.

For example, right now, due to a bug in the new preview generation code, 
if you're using trunk and you access the MythWeb Recorded Programs page, 
your backend will go to 100% CPU usage and may or may not recover 
(depending on certain factors).  At this point, recordings in progress 
may become corrupted, if using a combined frontend/backend, playback may 
suffer, and menus and other parts of the UI will seem sluggish (or 
downright slow, depending on your system).  To "fix" your backend, 
you'll need to restart mythbackend.  To work around the bug, you can 
either disable previews and preview generation for MythWeb or just never 
go to the Recorded Programs page.

How do I know this?  From reading the list and from experiencing it 
myself.  This is /exactly/ why we ask any user who runs SVN trunk to 
subscribe to /and/ read the -dev and -commits lists.  Those who don't 
tend to waste a lot of time reporting already-reported bugs or, worse, 
reporting "bugs" that are simply due to their failing to learn how to 
use new features that were fully explained in commit logs or other posts 
to the lists or their assumption that "nothing's changed."  All that 
wasted time is time that delays the next release and prevents creation 
of new features/bug fixes between releases.  (In other words, I think 
this can be summed up with:  If you can't /or/ you choose not to write 
code and fix bugs for MythTV, then please do your part and keep up with 
the lists so the devs can write code and fix bugs for MythTV.  So, it's 
a matter of how much time you're willing to put into MythTV for the code 
you're writing.  Waiting for 0.21's release is a much smaller 
committment of your time.)

> But seriously, I know I am not working on the edge of the
> capabilities. But It is nice to have a mythtv system that is stable
> for months without any bug-chasing. I would like to add some features
> to it now, so I start learning the basic plugin skills.
> 0.21 seems to be nicely maturing. I saw a few posts hinting at end of
> februari. That would be great. But I haven't seen a sort of freeze
> plan, so I will just wait and see for the moment. But once 0.21 hits
> the shelfs, I will move over my efforts to this release.

I think that's a very good plan.  For now, you may want to document in 
the wiki the fact that a major transition is occurring and that any new 
plugins should be written to use the new mythui and that a guide will be 
available shortly after the release of 0.21.  After all, the idea isn't 
to give people who might be considering creating brand-new plugins a 
head start on preparing for 0.21+, it's to give them the information 
they need to decide when to begin creation of new plugins and

And, really, there aren't that many new plugins that get created in any 
given 3-month period or so.


More information about the mythtv-dev mailing list