On Sat, Jan 10, 2009 at 4:29 AM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 01/08/2009 11:05 PM, Craig Sanders wrote:<br>
> On Thu, Jan 08, 2009 at 03:47:03PM -0800, Brad DerManouelian wrote:<br>
><br>
</div><div class="Ih2E3d">>> The supported method of running jobs on other machines that do not<br>
>> have tuners is to run mythjobqueue.<br>
>><br>
</div>...<br>
<div class="Ih2E3d">> the only mention of mythjobqueue in the manual is a few paragraphs at<br>
> section 23.25 - there's no mention anywhere in the manual that tunerless<br>
> backends are unsupported, or that mythjobqueue should be used instead of<br>
> mythbackend if no tuners are installed.<br>
<br>
</div>Note that if you run mythbackend on a host without any configured<br>
capture cards, all the parts of mythbackend that are not included in<br>
mythjobqueue are disabled--meaning you're basically running mythjobqueue<br>
+ cruft. "What cruft?" you may ask.<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">SNIPPED</blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Yeah, I realize that 256MiB of RAM isn't too expensive today, but why<br>
fill it up with garbage you're not using? Why not use it for something<br>
useful, like the kernel buffers/cache--or preventing mythtranscode or<br>
mythcommflag from hitting swap or ...<br>
<br>
And, as Brad has mentioned, since it was designed to be used that way,<br>
it's been tested that way.<br>
</blockquote><div><br>Just some background, and perhaps you guys would have a suggestion...<br><br> 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.<br>
<br>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.<br>
<br>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.<br><br>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.<br>
<br>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.<br>
<br>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. <br></div></div>