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

[Krzysztof Adamski]

On Fri, 2009-09-01 at 15:02 -0800, Brad DerManouelian wrote:
> 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.

Every time the "backend without tuners is not supported" comes up, I
can't stop wondering why not have a network tuner like the HDHR defined
on this tunerless backend. This would satisfy the requirement for tuners
without actually having a tuner in the backend.

K