I’ve had a MythTV box running for quite a few years now, but there’s always new things to learn, right? 🙂
My flatmate’s TV is in for repairs so we haven’t been using the box in the last few days, with a big NRL game on tonight it was supposed to be recording. I became concerned when the drive light wasn’t flashing as we ate dinner, a quick check of the web interface set my alarm bells ringing. Nothing was recording, and in fact nothing had been recording for nearly 2 days.
The time of failure co-incided with a machine lockup while we were trying to watch TV over the network (it’s saved as MPG so this is easy to do). With no TV screen I hadn’t verified that MythTV was working after the reboot, only that the SMB shares were alive. Visions of dead hard drives floated into my head as much frantic searching and diagnosis ensued 😉
The problem turned out to be very subtle, this explanation may get a bit technical but I couldn’t find any references to it on google so hopefully this post will be useful to someone else.
I only have one machine, but the log clearly said “Running as a slave backend“. Therein lies the problem, the Master server thought it was a Slave backend and sat there trying to connect to nothing. This means no scheduled recordings either because scheduling is all handled by the Master server 😦
MythTV is amazingly flexible. It handles multiple backend recording machines, each with multiple capture cards, as well as multiple frontends. Unfortunately a very flexible system easily leads to a lot of configuration complexity, a fact I know all to well from my time in ELJ support.
After browsing around various forms and mailing lists for nearly half an hour I ended up in the Configuring MythTV docs. If you scroll down to the general section, you’ll see some confusing paragraphs:
If you will be deploying multiple backends, or if your backend is on one system and you’re running the frontend on another machine then do not use the “127.0.0.1” IP address.
NOTE: If you modify the 127.0.0.1 address and use a “real” IP address, you must use real IP addresses in both fields, otherwise your frontend machines will generate “Unexpected response to MYTH_PROTO_VERSION” errors.
To understand that, you have to understand that everything in MythTV land is controlled by a single MySQL server. Both the Backend and Frontend sofware connect to the database, read config settings for their hostname (they’re designed to netboot on diskless machines) and then read the global Master Server IP to connect to.
I don’t know why this option exists, but one of those per-host config settings is a Backend Server IP.
And suddenly it hit me.
A week ago, I downloaded MythFrontend for OS X. This poor little iBook is too slow to actually watch TV, but before I discovered that it was the first time I had run a remote frontend so I had to change a few things to make it work. One of those was the Master Server IP.
Since this had been set to 127.0.0.1, the frontend couldn’t connect to the Master Server so I changed it to the Master Server’s network IP. The frontend worked, everything else seemed fine, so I thought nothing of it. Until the Server rebooted.
It turns out that when the Backend loads up, it compares Backend Server IP it has been assigned to the Master Server IP. If they match it loads as the Master; otherwise it becomes a slave. Apparently, it doesn’t bother to figure out that the Master Server IP is the same machine as the 127.0.0.1 it has been told it owns. Isn’t this option redundant? Can’t the Backend just check if it owns the Master Server IP when it already listens on all interfaces?
So long story short, if you mess with the MasterServerIP in your database make sure you also update the BackendServerIP listed in the settings for your Master Server’s hostname. ugh.
On the plus side, I think half an hour to fix a problem this subtle in configuration settings that I had no clue existed is a new record for me 🙂