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.

4 comments:

  1. I find that the "find_orphans.py" script does wonders with cleaning up failed recordings. http://www.mythtv.org/wiki/Find_orphans.py

    ReplyDelete
    Replies
    1. Thanks 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.

      Delete
  2. Paul, 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.

    Also, 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

    ReplyDelete
    Replies
    1. Jim,

      I 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

      Delete

Due to intermittent spamming, comments are being moderated. If this is your first time commenting on the blog, please read the Ground Rules for Comments. In particular, if you want to ask an operations research-related question not relevant to this post, consider asking it on Operations Research Stack Exchange.