[mythtv-users] Just upgraded to latest git and now I get "Protocol version check failure."

[R. G. Newbury]

On 05/19/2011 09:08 AM, Greg Grotsky wrote:
> So I upgraded mythtv last night to latest git pull.
>
> MythTV Version   : v0.25pre-2003-gfd5e33a
> MythTV Branch    : master
> Network Protocol : 65
> Library API      : 0.25.20110429-1
> QT Version       : 4.6.3
>
> I started up mythbackend... seems to be fine.  When I run the frontend it
> complains that it cannot communicate to the backend.
>
> 2011-05-19 06:54:58.709 MythCoreContext: Connecting to backend server:
> 192.168.0.10:6543 (try 1 of 1)
> 2011-05-19 06:54:58.709 MythSocket(ffffffffa8fd7c50:-1): writeStringList:
> Error, writeBlock failed. (UnknownError)
> 2011-05-19 06:54:58.710 MythSocket(ffffffffa8fd7c50:-1): readStringList:
> Error, called with unconnected socket.
> 2011-05-19 06:54:58.710 Protocol version check failure.
>                          The response to MYTH_PROTO_VERSION was empty.
>                          This happens when the backend is too busy to
> respond,
>                          or has deadlocked in due to bugs or hardware
> failure.

> This happens on the backend machine and on remote machines.  Also, trying to
> bring up mythweb I see this error:
>
> Unable to connect to the master backend at 192.168.0.10:6543.
> Is it running?
>
> 192.168.0.10 is the IP address of my backend server.  Not sure how to fix
> this, as I haven't changed anything configuration-wise, and I don't want to
> muck anything up further... anyone know what's going on here or how to fix
> it?

This error turns up on this list every couple of months and can turn out 
to be a number of different things. But it always appears to be related 
to mysql communications. Your problem is clearly related to the 'called 
with unconnected socket' error. This is a generalized list of steps to 
track down what went wrong.

First, do a database check for crashed tables. If this was the case, you 
are lucky! Ignore the rest of this!

Second, do a 'df -h' to check that you have not filled the partition 
where /var lives. If so, delete some log files. Find out what caused the 
over-run. Consider re-partitioning on your next full install.

Third, check that /var/lib/mysql and its subdirectories are owned by 
mysql:mysql (and not for example, root:root or mythtv:mythtv)

Fourth, if you can get there in mythfrontend, make sure that 
Setup->General-> page one, has the correct IP address for the machine 
with the mysql server ( you cannot use a hostname in this field: only on 
page 2). But you probably cannot get to there, since the FE won't start!

Fifth, exit the FE *and* BE and restart the *network* and then the 
*mysql daemon*. Ping the world. This will expose any structural errors 
in networking communication. If using multiple boxes make sure that 
networking is enabled in the my.cnf file. (That is, if the line 
'skip-networking is uncommented you cannot connect using TCPIP, -> fail 
for  multiple boxes. If you are on one box, then it can be uncommented, 
as connections are by sockets -> more secure.

Sixth, check that you can access the mysql daemon from the FE machine 
using the usual "mysql -u mythtv -p". This will reveal any errors in the 
'user+hostname' combination which should be an allowed known user 
according to mysql. This is an easy one to mess up!

Seventh, do 'select * from settings where value = "BackendServerIP";'
and 'select * from settings where value = "MasterServerIP";'
These should both return the correct IP address and hostname of your 
mysql server machine. (Why or how they could get munged is...an exercise 
left to the student to complete in spare time!)

Eighth, restart the backend in a console with '-v all' checking that it 
comes up properly. If so, restart it as a service, with at least '-v 
database -l /var/log/mythbackend.log' and then check the log file (this 
checks for misconfigurations in the /etc/sysconfig/mythbackend and 
/etc/rc.d/init.d/mythbackend startup files (file locations for fedora)

Ninth, start the frontend also with logging, in a console and alt-tab to 
the console to watch what happens.
Hopefully, success!

My experience is that filling the partition is the most usual route to 
this error, for a longtime stable computer. An upgrade or other change 
messes up something..the logging runs away with errors, the partition 
fills and mungs the database. Which explains why /var is a separate 
partion on my box and I symlink /var/lib/mysql to /home/mysql to 
separate the database from /var.

An upgrade to the box, or an infelicitous change, aside from a myth 
upgrade can change file ownership or permissions.
An upgrade to the box can over-write the mysql database, so it does not 
'know' about user mythtv.
Good luck.























              R. Geoffrey Newbury