[mythtv] MythTV: Isaac Tivo: > 100 tech guys
kevin at phunc.com
Wed Dec 8 04:26:44 UTC 2004
----- Original Message -----
From: "Isaac Richards" <ijr at case.edu>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Tuesday, December 07, 2004 5:38 PM
Subject: Re: [mythtv] MythTV: Isaac Tivo: > 100 tech guys
Isaac, a very positive response, thank you.
> I suggest that you review them again. Quite a bit has changed. Certainly
> lot of translation work has been done, but, that's to be expected, no?
Indeed, I don't think the translation patches are meaningless, in fact, they
quite important simply because it opens up MythTV to the rest of the world.
> I've been spending much of my free time in the past several months
> my basement. The rest of the time I have to spend on Myth is generally
> applying patches that people send in. I really wanted to have been
> re-writing all the UI code to use the mythui library I wrote a while back
> now, but I simply haven't had time yet.
Certainly everyone disappears, or takes small breaks, from a project during
major life circumstances. After all, as much as we would all love to
lives to a PVR, the reality is that everyone works, sleeps, loves, etc.
Agreed on this.
> You're right - I won't put much stock into someone else tell me how to
> something, especially when that person has no intention of writing any
Since the project is indeed yours, you have every right to do that. It
mean you are selfish, or have poor character; you simply want things done a
way. My only point was, since you aren't very receptive to the coordination
always, I believe the "forward movement" of MythTV has been stunted.
people looking in who have no intention on writing code don't deserve to
decisions, but hasn't there been times on the mailing lists and IRC from
who thought the module interaction and database foundation could use some
> But, then again, I don't much recall someone suggesting any sweeping
> recently. Well, maybe the multi-database support, but there was a nice
> compromise worked out, I believe.
Not so much recently. I think it has just been over the last year or so as a
> I would _really_ like to see when I've said that. The only time I can
> was when someone was trying to re-design the music database schema, and
> did a
> very poor job of it (ie, much, much slower than the current schema for
I can recall many times on IRC when you've explicitly stated that you will
code that is slower than existing code, regardless if it's even just a
fraction of a second
slower in total and adds new functionality. Certainly optimization and
important, but where is the line drawn?
> If someone were to propose a 'play music anywhere' extension at the
> though, I certailny I would reject it. Mfd (and mfe) exist in CVS for
> this purpose, and will be merged in to the main mythtv/mythmusic trees
> whenever Thor is happy with his code.
> I don't know what you're talking about with 'communication between
> because such things can easily be taken care of by using existing message
> passing structure that has existed ever since the frontend and backend
So you would be willing to work with / allow people to implement interaction
> Yeah, that's why I'm completely rejecting multi-database support.
>> Even more so, developing modules in general are overly complicated
>> than what they should be. Even some of the once deemed "bad" Windows
>> PVRs are ages ahead in that sense, some having tens of plugins, most of
>> which are quite solid.
> More people use Windows than Linux. If I had started this project on
> I'd have a few orders of magnitude more users and contributors, just like
> those other projects you mention.
In partial agreement with you, yes, people interested in using and
PVR software on Linux is a smaller "market." But there are PVRs that have
been in development much less than MythTV, with a much smaller codebase,
small group of developers and users, but still have passed up MythTV.
> Honestly, what's wrong with the current structure?
Well, again only IMHO:
1) Over complicated "plugin" design
2) No solid and documented module interaction system to allow MythX to
run and be controlled by MythY.
3) Heavy dependancy requirements
4) Lack of any development documentation, guides and API specifications
I am stopping short because I'm beginning to feel like a jerk who is picking
I should clarify, that while in some senses I am complaining, I think that
far has been very suitable, given the price tag. It is a nice piece of
software. It is just
very far behind in many ways from the rest of the pack, when it use to be
Isaac, would you be interested in holding a "MythTV Conference Meeting" on
specific date/time to discuss current goals and potential development
this could be useful to help in coordinating development efforts?
kevin at phunc.com
More information about the mythtv-dev