To understand both the problem and what appears to be the solution (knock on virtual wood), you have to know a bit about my setup. I have a PC dedicated to recording and replaying TV. The front and back ends of MythTV are both on that box. The box has three network connections:
- eth0 is a built-in (and unused) Ethernet port;
- eth1 is a Hauppauge WinTV-DCR external TV tuner, connected via USB; and
- wlan0 is a wireless network adapter, connecting the PC to my home WiFi network (I have DSL service with a DSL modem that also serves as gateway and WiFi router).
After more adventures with Google, including the discovery of a proposed workaround in this bug ticket, I found a combination of things that seems to have worked. On three successive reboots the front end has been able to converse with the back end, I have been able to schedule recordings, and the PC can see the tuner. I've yet to actually record something, but I'm cautiously optimistic.
I don't know if all the following steps are necessary, and I'm not going to experiment further unless the system breaks again. What I did was:
- disabled IPv6 as described in the bug ticket (which, from experience, was not sufficient in and of itself);
- assigned the wireless connection on the PC (wlan0) a static IP address within the range supported by my DSL modem;
- ran the back end setup program and changed the IP address of both local and master back ends (which are the same in my case) to that static IP address; and
- changed the IPv6 settings for both eth0 and eth1 from "automatic" to "ignore".
That leaves me with one mildly annoying problem. During the period where the front and back ends were not communicating, MythTV failed to record a few scheduled programs. One of them appears in the list of recorded shows with a size of 1 byte. This by itself is not the issue. What's annoying is that it appears in the list 1,100 times! Or at least it did: I've gotten it down to a bit over 1,000 by manually deleting the entries one at a time. I'm hoping there's a clever and much more efficient way to get rid of the rest. Ordinarily I'd crank up the MySQL command client and run a delete query on the database, but the MythTV database has quite a few tables, I'm not sure what all I would have to delete, and I really don't want to mess up the database.
I find that the "find_orphans.py" script does wonders with cleaning up failed recordings. http://www.mythtv.org/wiki/Find_orphans.py
ReplyDeleteThanks for the tip! I downloaded and ran the script. It didn't find any orphans (which is a good thing, as I've cleaned out all the orphans I mentioned above). I'm keeping the script around just in case.
DeletePaul, I was reading through your blog, which I only discovered today. I think the static IP are a good idea in general for a server (and this certainly qualifies) as you'll eventually find a need to monitor this or that service internally and it's nice if you can refer to them using the same IP address over time.
ReplyDeleteAlso, I wonder if your original problem is related to some combination of DHCP assignment delay and startup of the mySQL listener. It seems the front end should probably be started after the backend service is fully running (and it may or may not continue to poll for a long enough time after a restart). Hardcoding the IP address certainly shortened the time from boot to live for both of these services. MySQL may also have taken on enough entries (I'm not familiar with the MythTV database, but I've done LOTS of work with MySQL) that it's also taking a bit longer to bring up services than it did as a clean install.
The problem with these sorts of patchwork service busses can come down to simple synchronization. If your front end has 15 seconds to find and connect to the back end before it gives up and it's init fails.
It is still a guess until I get my tuner card and time to play with it, BUT I suspect the best order for services to start is MySQL, Mythbackend, MythFrontend. rcconf can force MySQL to start as a boot service. update_rc can force the others to wait for their respective dependencies.
Does this make sense? I'd like to know, because, depending on ease of MythTV streaming the 4 tuners, I may soon be following in your footsteps.
Best Regards,
Jim O'Donnell
Jim,
DeleteI don't think the MySQL database is overly large -- if I'm looking at the correct file, it's around 27MB -- but of course how long it takes the MySQL daemon to get up to speed is a function of a bunch of things, including machine speed (this box is okay but no screamer).
I've had no further connection problems since I nuked IPv6, so my inclination is to believe that a Mythubuntu system update did something that affected IP settings and triggered the issue. I agree that all sorts of things can turn out to be startup timing glitches, but if that were the case here then I would expect the problem to recur at some point, and it hasn't to date.
The one remaining question mark with my setup is that the PC does an ACPI wake-from-the-dead at 00:00 GMT. I'm not sure that it does it every day (though I'm often not around to see it if it does), and I have no idea what's triggering it. I think I've seen sporadic reports of the same problem or something similar, so I'm wondering if maybe it's a matter of what BIOS I have.
Cheers,
Paul