[mythtv-users] backends without tuners (was Re: Transcoding is being done on frontends, not backend)

Brad DerManouelian myth at dermanouelian.com
Fri Jan 9 23:02:21 UTC 2009


On Jan 9, 2009, at 2:57 PM, Bill Williamson wrote:

> SNIPPED
>
> Yeah, I realize that 256MiB of RAM isn't too expensive today, but why
> fill it up with garbage you're not using?  Why not use it for  
> something
> useful, like the kernel buffers/cache--or preventing mythtranscode or
> mythcommflag from hitting swap or ...
>
> And, as Brad has mentioned, since it was designed to be used that way,
> it's been tested that way.
>
> Just some background, and perhaps you guys would have a suggestion...
>
>  I have three myth frontends, and (currently, I abandoned plans) one  
> backend.  Due to unknown issues (which laters kernels fixed, this  
> was 18 months ago) my tuner cards would lock up forcing a HARD  
> reboot about once per week or two.  It was also taking a long while  
> to reboot (my best guess is an interrupt problem was causing  
> everything, not the tuners themselves), and if it happened when I  
> was at work the wife and baby had no TV for the day.
>
> My first proposal was to stick ALL hard drives (apart from small  
> boot drives) onto a seperate server and mount via NFS.  This fixed  
> part of the issue (she coudl still watch movies) but still meant she  
> couldn't watch recorded shows nor use the myth gui for watching  
> anything.
>
> The "root" problem with this setup is that mythfrontend MUST connect  
> to the MASTER backend (and mysql) on startup and while doing other  
> things in and about the code.
>
> So my second proposal (which the list commented was the best  
> solution) was to run a master "server" with all my storage (and NFS  
> server), mysql, mythbackend (no tuners), asterisk (but no phone  
> cards, same issue as myth and tuners), etc.  All of my core  
> "services".  Then I could run one (or more) secondary backends with  
> tuners, and if they had to be cut off and back on then it DID effect  
> recording, but didn't effect watching.   This seemed to be the  
> perfect solution, and something I was going to move to in the future.
>
> I was basically told that running this way would do all scheduling  
> and (if I hit the "force master backend" switch, or just used NFS)  
> file transfer, and optionally (depending on how i configured)  
> commercial detection.
>
> Is there a large reason this isn't supported?  It seems like an  
> ideal situation for anyone with a large (or even medium) myth farm.

I think you SNIPPED the reason when you replied. Also, the ideal  
solution is to not have a backend that locks up. Fixing that instead  
of putting time and effort into changing your entire system to work  
around it seems like a better use of time to me. The biggest reason  
not to do it, again, is that it is not tested. It might work, it might  
break. No one even tries and if there is a problem with it, no one  
will fix it.



More information about the mythtv-users mailing list