Wednesday, September 5, 2012

Mythtery Solved?

Previously, I described a problem with my Mythbuntu installation that developed suddenly on August 24 (meaning that the system worked fine from installation this past May through August 23, then stopped working on the 24th). The symptom was a failure by the front end (and by the Mythwelcome application) to connect to the back end. It seemed possibly to have something to do with using IPv6 rather than IPv4, specifically on the wireless LAN connection. I won't repeat all the gory details but instead refer you to the previous post (if you care).

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 wearing out Google trying to find solutions, I came across something that made me think that turning off both Ethernet ports would resolve the problem. I'm not sure why it would, given that error messages in the back end log typically referred to problems with wlan0, but I gave it a try. In a sense it worked: with both Ethernet ports disabled, the front end had no problem talking to the back end. Unfortunately, disabling eth1 meant that the back end could not see the tuner card, so it would dutifully wake the PC at the designated time and try to record a show, but fail miserably (and silently). Disabling just eth0 was not enough; the front end and back end were again not on speaking terms.

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".
I have no problem with having to disable IPv6; it's not as if my home WiFi network is going to run short of addresses with IPv4. I don't know why the last step was necessary given the first step, but from experience it was. I don't know if the first step is necessary given the last step. Basically, my answer to any question about this (after being stripped of expletives) is "I don't know". I just hope the fix holds up.

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.