[mythtv-users] How MANY backend threads!?!?!?

Steve Smith st3v3.sm1th at gmail.com
Thu Oct 14 21:17:57 UTC 2010


20 year old apis? That'll be 8086? Mpeg?
I think this is a symptom of the BE getting too monolithic. A more
modular approach would enable more flexibility without having to be
always playing catchup. I've mentioned in a previous thread how it'd
be good to have a core protocol for basic functions so you can use
older FE
with a new BE and still get basic functions.
But heh it's not my project and i dont have time to wade through the
code trying to backport the bits in the 23 BE that i want to 21.


On 10/14/10, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>   On 10/14/2010 04:02 AM, Paul Gray wrote:
>> On 14/10/2010 00:07, Robert McNamara wrote:
>>> I want to clarify that it is a *totally valid option* to remain at a
>>> given release of MythTV.  I just want people to start realizing that
>>> perpetually upgrading with the same hardware is not going to be
>>> possible forever, and that some of the new features planned on both
>>> front and backend may make the idea of running *new* versions of myth
>>> on whatever you can find in your closet impossible.
>>>
>>> We'd love for everyone to join us on the journey, but we're absolutely
>>> okay with the people who can or will only run on old or low power
>>> hardware putting the brakes on.  That's a matter of the user's
>>> priorities-- they just can't fault the devs when our priorities don't
>>> align.
>>
>> Seems fair enough, but also surprising: MythTv is traditionally so very
>> configurable. What sort of things are planned that it wont be possible
>> to turn off for low-powered hardware?
>
> It's not about adding things that will require more resources, but about
> dropping support for ancient (20-year old) APIs that require parallel
> coding--meaning that we have 2 or more full implementations of some
> major pieces of functionality.  And, since the multiple APIs we
> currently support have differing capabilities, every time a modification
> is required, we have to choose between greatest-common divisor approach,
> making basic functionality differ depending on which API is used, or
> adding additional code to try to simulate unsupported functionality with
> the older API.  And in truth, keeping just one implementation working
> properly is difficult enough.
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

-- 
Sent from my mobile device


More information about the mythtv-users mailing list