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

[Michael Watson]

On 17/09/2011 04:23, Michael T. Dean wrote:
> 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
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

What is your network connection between the frontend / backend?  Is it 
wireless or wired?
Is the Backend / Frontend doing anything CPU / Disk Intensive at the 
time you get the MYTH_PROTO_VERSION errors?
What are the Specs of the two Systems?  CPU / RAM / Network Speed

I have seen these errors when either trying to use a wireless connection 
(ie, network throughput is not fast
enough for MythTV to work properly, or when Local tasks on either the 
Frontend or the Backend are bogging
down the system, so either are unable to respond fast enough to work 
properly.

Michael