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