[mythtv] Will it be accepted if I write it.

[Robert Middleswarth]

Isaac Richards wrote:

>On Monday 03 October 2005 06:02 pm, Robert Middleswarth wrote:
>  
>
>>Well fighting with a problem I had last week with my home network of
>>myth backends I was looking at ways to try and make mythtv both easier
>>to find problems and second when something does go wrong it takes less
>>down in the process.  I missed several nights worth of shows because
>>myth handed crashed but it just stoped starting new recordings so it
>>looked like it was running but wasn't.
>>
>>My Idea is to break down mythbackend into several smaller pices so that
>>if a bad command comes into the backend from a slave it wont also take
>>out the masters abilty to record and also the other slaves abilty as
>>well.  So I might miss one shown instead of an entire night worth in the
>>event of a problem.
>>
>>To put it simply.  I want to start by 1st going thought and tring to
>>move threads out from mythbackend and into separt programs like
>>mythbackendschd, mythbackendtalk, etc. it might take me a while but
>>before I start put time towards that end I wanted to hear from to core
>>developers if that would be accepted if writen.
>>    
>>
>
>I'm not entirely sure what the benefit would be.  You'd have to have some ipc 
>mechanism between the various processes, and I think you'd just be 
>duplicating the existing issues with that, really..  The existing 
>communications between backends and frontends is just that, really, and you'd 
>be splitting things up even more.  I think it'd just lead to more problems, 
>myself.
>
>Might be easier to fix the bugs causing things to stop responding, instead. =)
>
>Isaac
>_______________________________________________
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
>http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>  
>
My goal like your is to make mythtv the best it can be so it comes down 
to the following befits as I see them.

1) It is the postfix/qmail ver sendmail question is it better to have 
one program that does everything or a bunch of smaller programs that do 
parts of the big picture.  Not all parts of mythbackend need to talk to 
each other for instance if you are watching a recording all that is 
needed is a lock that say this video is being watched no ipc needed 
there other then the current frontend/backend that is all ready in place 
and I am sure there are other parts of mythbackend that don't need 
anything more then mysql access to work. 

2) Memory.  If designed so that only time the recording part of 
mythbackend is running is when actually recording then memory would be 
freed when not in use and lets say that a small memory leak exists in 
that part of mythbackend then when as a separt program it stops running 
all the memory gets released and it gets freed instead of now where it 
slowly grows on you.

3) Yes some from of IPC will likely be needed but yet something can be 
done without complex IPC having to be created and in my view smaller 
programs that do less will make finding problems easier as there is less 
code that needs to reviewed to find memory leaks and other problems.

4) Because of the complexity of mythtv there will always be a few parts 
of mythtv that will be unstable as you are dealing with analog data that 
the program has no control over but if you keep the unstable parts 
separt from the parts that you can make very stable then if one part 
crashes it doesn't tend to take the whole system down and has more 
ability to recover better.  Example driver glitch that crashes a 
recording now is likely to affect the whole system but under a separt 
process it would more likely only effect that recording.

In the end I am was just asking if it might be accepted into the main 
tree if you or the core developer view this a bad idea and it will not 
be accepted I will back off from the idea.  If it might I will start 
work on some of the easier parts leaving most of mythbackend in place 
and just tiring to break off small parts with limited IPC requirements 
into sub pieces and submit those for review and possible inclusion into 
head development.

Robert