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

Fri May 20 02:57:30 UTC 2011

Thanks for the response Geoffrey.  I've looked through your list and I
wasn't able to find anything amiss :-/, see responses below.

On Thu, May 19, 2011 at 8:27 AM, R. G. Newbury <newbury at mandamus.org> wrote:

> 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!
>
> Did the check and all was well.

> 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.
>
> df -h shows my partition with the least amount of available space has 25G
free on it.  Root '/' where the /var lives has 57G free.

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

> 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!
>
> Strangely my mythfrontend actually appears to work, for the most part.  I
just can't see any recordings and I cannot play any of my videos.  But the
frontend shows up with my settings and I can see some information like what
jobs are currently running on the backend - but I can't see the backend
status.  I CAN see the program guide and previously recorded but CANNOT see
the upcoming recordings nor recording rules!

  Weird, I had a problem a long time ago where I was using a hostname
instead of an IP address in myth and it caused some issues but I couldn't
get to any content AND the frontend popped up a message complaining about
"unable to communicate to backend" but that's not happening now.

> 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.
>
> I rebooted my machine this morning hoping that would make a difference but
no love.

> 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!
>
> This works well.

> 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!)
>
> I did this and I get the IP addresses that I expect.

> 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)
>
> This is interesting, I did restart them with -v all and noticed that it
reports specific mysql calls.  So I restarted with just -v database and I
see it talking to the DB and getting results.  For some reason it still
complains about not being able to talk to the server.

2011-05-19 20:10:10.701 mythfrontend version: master
[v0.25pre-2003-gfd5e33a] www.mythtv.org
2011-05-19 20:10:10.708 Using runtime prefix = /mythtv/local64
2011-05-19 20:10:10.708 Using configuration directory =
/home/spikeygg/.mythtv
2011-05-19 20:10:10.710 ThreadPool:HTTP: Initial 1, Max 25, Timeout 60000
2011-05-19 20:10:11.131 Empty LocalHostName.
2011-05-19 20:10:11.131 Using localhost value of mythbox
2011-05-19 20:10:11.131 Clearing Settings Cache.
2011-05-19 20:10:11.132 Testing network connectivity to '192.168.0.10'
2011-05-19 20:10:11.235 Clearing Settings Cache.
2011-05-19 20:10:11.260 New DB connection, total: 1
2011-05-19 20:10:11.263 Connected to database 'mythconverg' at host:
192.168.0.10
2011-05-19 20:10:11.266 Closing DB connection named 'DBManager0'
2011-05-19 20:10:11.267 Clearing Settings Cache.
2011-05-19 20:10:11.267 Connected to database 'mythconverg' at host:
192.168.0.10
2011-05-19 20:10:11.268 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'language' AND hostname = 'mythbox' <<<< Returns 1
row(s)
2011-05-19 20:10:11.269 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'country' AND hostname = 'mythbox' <<<< Returns 1
row(s)
2011-05-19 20:10:11.269 Current locale en_US
2011-05-19 20:10:11.269 Reading locale defaults from
/mythtv/local64/share/mythtv//locales/en_us.xml
2011-05-19 20:10:11.270 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'freqtable' AND hostname = 'mythbox' <<<< Returns 0
row(s)
2011-05-19 20:10:11.271 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'freqtable' AND hostname IS NULL <<<< Returns 1
row(s)
2011-05-19 20:10:11.271 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'iso639language0' AND hostname = 'mythbox' <<<<
Returns 0 row(s)
2011-05-19 20:10:11.272 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'iso639language0' AND hostname IS NULL <<<< Returns 1
row(s)
2011-05-19 20:10:11.272 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'iso639language1' AND hostname = 'mythbox' <<<<
Returns 0 row(s)
2011-05-19 20:10:11.273 MSqlQuery::exec(DBManager0) SELECT data FROM
settings WHERE value = 'iso639language1' AND hostname IS NULL <<<< Returns 1
row(s)

> 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.
>
> Yeah, I am always weary of upgrading the distro.  I didn't do anything like
that this time though, it was a simple 'git pull' and recompile.  I don't
really know what else to try...  Please help!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20110519/51d67a29/attachment.html 