My Mythbuntu installation abruptly decided, starting around August 24, to malfunction. The system is set up to boot straight into MythTV, meaning that the back end server starts automatically at boot, Mythwelcome starts automatically, and Mythwelcome in turn starts the front end automatically. The back end and front end are on the same box, with IPv4 address 127.0.0.1 and IPv6 address [::1]. The box is connected to my home wireless network (DHCP address). The PC also has an Ethernet card that is not connected to anything (and has not been since before I installed Mythbuntu).
Things worked fine for several months, but starting four days ago I observed the following symptoms after a boot:
- The front end generated an error message: "Could not connect to the master backend server. Is it running? Is the IP address set for it in mythtv-setup correct?"
- A Python script (sendProfile.py) would attempt to send a bug report and would itself crash with "Failed to connect to backend at 127.0.0.1:6543" (which should be the correct address).
I checked the back end configuration, and it was correct (127.0.0.1, [::1]). Interestingly, running through the configuration program would temporarily solve the problem (until the next boot) or break things totally. Success apparently occurred because the configuration program forces you to shut down the back end (which it restarts when you exit configuration). Failure occurred occasionally (but not always) because the initial shut down apparently did not succeed, and after I exited the configuration program I wound up with two separate mythbackend processes.
Anyway, for what it's worth, I discovered that if I exited the front end and killed the back end with sudo kill -9 <process id>, the back end would automatically restart, the front end would be able to connect to it, and all would be fine ... until the next boot.
Looking in the back end log file, I found that prior to the 24th there would be messages saying the backend was listening on TCP [::1]:6544 or TCP 127.0.0.1:6543, which was as it should be. From the 24th onward, the corresponding messages would mention TCP [fe80::218:37ff:f32b:100d%wlan0]:6544 (or 6543), with a failure message if it was after a reboot (success if it was after my kill -9 ministrations), or TCP [fe80::20d:feff:fe7e:455b%eth1]:6544 (or 6543) with apparent success, not that it did me any good. My best guess is that the change was prompted by my installing a system update, since I certainly did not touch any configuration files, or anything else, directly.
Various web searches turned up nothing useful, until I stumbled across a post from someone encountering a similar but different problem running MythTV on Windows. The cure for him was to disable his Ethernet adapter. So I changed the settings for the eth0 and eth1 interfaces on my system so that (a) they don't automatically try to connect and (b) users do not automatically have access. After a reboot, everything appeared to work. After a second reboot (I have a suspicious nature), it still worked. I'm tentatively declaring victory, but I hope someone fixes this (without breaking something else) in a future update.
Update: Boy, was that ever a mistake! Everything looked fine, until I recently discovered that nothing was recording. The PC woke on time, Mythwelcome showed the correct information for upcoming recordings, there were no error messages (until I looked in the logs) ... but when the time to record a show came, the backend experienced an error and the show went unrecorded. Midway through an afternoon of log parsing and repair attempts, I discovered that MythTV could no longer see my external tuner card (a Hauppauge WinTV-DCR that MythTV thinks is an HDHomeRun Prime). The tuner communicates via a nonrouteable local IP address, and even though it plugs into a USB port, it apparently counts as one of the Ethernet ports (probably eth1, but I'm not certain about that). When I set both interfaces to turn on manually and restricted them to root access, I guess I effectively disconnected the tuner card. Oops!
Update 2: I may have fixed it. Details are posted here.