<br><br>
<div class="gmail_quote">On Fri, May 22, 2009 at 2:35 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">On 05/22/2009 01:05 PM, Josh White wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Assuming you've read the previous information, you'll have some idea of what I'm trying to do...but feel free to ask if more clarifacation is necessary. The problem I'm experiencing concerns the two backends communictating with each other. When I finally had both systems up and running, and configured in a way that I believe to be correct, the tuners in my remote frontend fail to work. They fail to work regardless of whether I'm attempting to connect to them from either machine. The remote backend in this case will be unable to display live tv of any kind, but will be able to display videos & recordings. The strange thing is that after a week or so, and a few reboots/mythfilldatabase runs, the tuners begin to work in the remote backend. I verified yesterday that all 4 tuners were working by watching 4 different channels on 4 different frontends simultaneously. They generally continue to work for a while (days, assuming I leave everything running), but at some point, one of the tuners on my master backend will show up as "unavailable" but 3 tuners will continue to work (I'm not sure how long it takes for this behavior to manifest itself). I'll reboot the master & the remote backends, and then I'll be in the situation where the remote backend will fail to work, but both tuners in my master backend will work...until all 4 start working again, some time later.<br>
</blockquote><br></div>I've seen similar issues where working capture devices just stop working with Myth due to broken capture card/input connections configuration. I'd recommend the first step in fixing it is the (capture card /and/ video sources portion of) <a href="http://www.gossamer-threads.com/lists/mythtv/users/264034#264034" target="_blank">http://www.gossamer-threads.com/lists/mythtv/users/264034#264034</a> (to ensure you have a clean configuration).
<div class="im"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"> One issue that I'm unclear of, is what order the machines must boot. I would assume the master should be running first,<br>
</blockquote><br></div>Yep, ideally. Though the slave should try to reconnect if the master is not running when the remote backend first tries to connect. However, if MySQL is unavailable when the remote backend tries to start, the remote mythbackend process will shut down. (Actually, it's a bit more complex than that, but see <a href="http://www.gossamer-threads.com/lists/mythtv/users/370119#370119" target="_blank">http://www.gossamer-threads.com/lists/mythtv/users/370119#370119</a> for more--but not all--details.)
<div class="im"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">so the remote machine has something to connect to. It should also be noted that while I am currently running Mythbuntu/Ubuntu 9.04, I experienced the same symptoms/behavior while running 8.10.<br>
</blockquote><br></div>Also, make sure you check that the remote mythbackend process is actually running. If there's no network when it starts (which is a common problem with a certain distro's making networking reliant on the GUI), the backend will shut down.<br>
<br>Mike<br>_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
</blockquote></div>
<div><br>I'm pretty confident in my tuner configuration; I've checked that many times, and whenever I do make a change, I delete and re-do all of it. </div>
<div> </div>
<div>In general, what I gather from what you say is that my problem could likely have to do with the order the backend process and the networking processes start. If the machine tries to load the backend before there's a network connection, the backend process will stop itself because it cannot communicate. I believe I've seen this occur, and I was able to make it work (accidentally) by running mythfilldatabase after exiting mythbackend-setup (which stops/starts the backend process in the process). Since the machine was completely up and running, the network was present, and when the backend process was restarted...ah ha!</div>
<div> </div>
<div>So to me, it would seem logical to make sure the order in which these processes start are what they should be. This is something I'm not very familiar with...the closest thing I've configured like this would probably be the autoexec.bat file on my old 486sx running DOS 6.2. Is there an analogous file(s) that I could simply reorder to guarantee that things load in the proper order? One would think that the Mythbuntu people would handle that, but I'm clearly unaware of all that goes into this. If that's not possible, then would it be possible to write a simple script to verify mythbackend is running at the end of the boot cycle, starting it if not?</div>
<div> </div>
<div>My hardware and software configuration isn't that exotic, it seems strange that such a basic issue could be causing my trouble. </div>