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

[Michael T. Dean]

  On 10/14/2010 06:12 PM, Mike Perkins wrote:
> Steve Smith wrote:
>>
>> 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.
>>
> It might be useful if the spawned parts of mythbackend actually had 
> different names so one could figure out what was happening. 32 threads 
> of 'mythbackend' isn't really meaningful, whereas if some of them 
> were, I dunno, 'mythgenpreview' for example, one could see what was what.

That specific part is already done for 0.24--mythpreviewgen generates 
previews.

>
> We already have 'mythtranscode', 'mytharchive',... so why not extend 
> this scheme to forked processes? I understand it might not be so easy 
> with threads, but still...
>
> There are a number of unix examples of programs which are the same 
> binary but behave differently according to what name they are called with.

Chris Pinkham and I are both hoping to break the different parts 
(recording, job queue, scheduling) of the backend out into separate 
pieces.  This would have many benefits:
   a) would allow you to run the master backend (scheduling portion) on 
a system without capture cards
   b) would make all backends (recording and job queue portions) 
"remote" (separate process from the scheduling portion) so all 
scheduling to backend communications and interaction would be identical 
(making setup and configuration easier)
   c) many more benefits that I haven't even started to consider

On each system you'd just start up mythbackend and it would start the 
daemon processes that handle the parts that system wants to run.

But (speaking generally, to anyone reading), as Jarod said, patches 
speak much louder than ideas.  We're not lacking ideas to improve 
MythTV--we're mainly lacking code and the time to implement said code.

Mike