[mythtv-users] Sometimes: Protocol version check failure. The response to MYTH_PROTO_VERSION was empty.

[Michael T. Dean]

On 09/16/2011 05:12 AM, Michael Watson wrote:
> On 16/09/2011 06:58, Robert Verspuy wrote:
>> I've been using mythtv for several years now and I'm a very happy user.
>> I'm currently upgrading to my 4th mythtv hardware and this will be the
>> first time where I'm going to separate the backend and the frontend.
>>
>> I've setup a new system with CentOS 6 (mythtv-backend 0.24.1-277.el6
>> latest from atrpms repo)
>>
>> MythTV Version   : v0.24.1-80-g1de0431
...
>> But when connecting to the server from a mythfrontend running on my
>> notebook I sometimes get the following error message:
>>
>> 2011-09-15 22:39:22.749 MythCoreContext: Connecting to backend server:
>> 10.84.100.60:6543 (try 1 of 1)
>> 2011-09-15 22:39:29.755 MythSocket(7fc77c0126f0:49): readStringList:
>> Error, timed out after 7000 ms.
>> 2011-09-15 22:39:29.755 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.
>>
>> In mythtv (on the backend), I've setup the ip-address and master backend
>> address to 10.84.100.60.
>> On the frontend I'm also using the same ip-address (no hostnames
>> anywhere in the config).
>>
>> When I run mythbackend normal (like a daemon through
>> "/etc/init.d/mythbackend start"), I'm getting the "MYTH_PROTO_VERSION
>> was empty" in the frontend and in mythweb at every attempt.
>> When I run mythbackend inside gdb, then sometimes it works without any
>> problems (I can see the program guide, recorded programs in mythfrontend
>> and mythweb and I can watch a recording in the frontend).
>>
>> So maybe this is a timing / locking issue??
>> Can someone point me into where to further debug this issue?
>>
>> The old backend/frontend is still running on the old hardware (although
>> I've only got 5% diskspace left :) , so I can test / try anything with
>> the new setup.
> The FE's ip address should not be the same as the BE IP Address, (each
> network device needs a unique IP Address)
> Change the IP Address of your FE to something like 10.84.100.61.  (Just
> a guess, as you haven't supplied the subnet mask you are using)

Though if you meant that you are "using the same [master backend] 
ip-address" setting value on the frontend host, that's a good thing.

As far as the backend lockups go ("Protocol version check failure. The 
response to MYTH_PROTO_VERSION was empty." means that the backend never 
responded to the client's connection request--which happens because your 
master backend is locked up), it's possible that the 
unstable/development code in the master branch has fixed the issue.

Generally, if you're getting these in 0.24-fixes, there's nothing you'll 
be able to do to prevent them from occurring.  So that means you could 
stay on 0.24-fixes and restart things every once in a while when the 
master backend locks up, or your could try upgrading to the 
unstable/development code--which might mean that backend doesn't lock up 
due to whatever issue is causing the problems on your system.  However, 
note that a) it's unstable/development code, so it may not work 
properly, and you should really read all the messages on the -commits 
list and -dev list if you're running it and b) upgrading is a one way 
path--you can't downgrade the database after an upgrade.

So, if you do decide to upgrade to unstable, I recommend you create a 
database backup ( http://www.mythtv.org/wiki/Database_Backup_and_Restore 
), then test out the new version.  If you have the same lockups in 
unstable, please let us know, and then you can shut down all of MythTV, 
downgrade all MythTV backends and frontends to 0.24-fixes, and restore 
the 0.24-fixes database backup you made just before upgrading ( 
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Replacing_an_existing_database 
).  Then, you can run http://www.mythtv.org/wiki/Find_orphans.py and 
move any recordings it lists as "Orphaned video files" to the MythVideo 
directories.

Or, if you have time to keep your "primary" system on 0.24-fixes and try 
unstable on the "test" system, you don't have to worry about the 
database data (since it's not actually recording anything new, I guess?).

Mike