[sparticle]

MythTVbackend Ver 0.25 + current updates running on Ubuntu 12.04.2
local XBMC Gotham current version (updated earlier today)
PVR addon Ver. 1.8.11

Remote XBMCBuntu Client 12.2 FRODO
PVR addon Ver. 1.6.9

Please see below log errors caused when the XBMC client connects to MythTVbackend. Also see transcript from chat on the mythtv IRC support channel.

mythbackend[3351]: C ProcessRequest mainserver.cpp:1259 (HandleVersion) MainServer::HandleVersion - Client speaks protocol version 8 but we speak 72!
mythbackend[3351]: W ProcessRequest mainserver.cpp:5801 (connectionClosed) MainServer: Unknown socket closing MythSocket(0x1244d50)

Above repeated every time client connects.
[20:37] <spart> does anyone know what these log entries mean:
[20:37] mythbackend[15852]: C ProcessRequest mainserver.cpp:1259 (HandleVersion) MainServer::HandleVersion - Client speaks protocol version 8 but we speak 72!
[20:38] <spart> mythbackend[15852]: W ProcessRequest mainserver.cpp:5801 (connectionClosed) MainServer: Unknown socket closing MythSocket(0x121c790)
[20:38] <spart> there ar a lot of them in mysysloig when MythTVbackend is running
[21:19] <lautriv> spart, looks like one of your frontends is from the stoneage
[21:21] <spart> don't get it all except MythTVbackend machine are XBMC 12.2 (current stable) clients
[21:27] <spart> lautriv, It seems that the XBMC client (Gotham on the MythTVbackend box) when it connects and syncs TV channels, Recordings and EPG info I get the syslog messages

Any further info needed please ask.

Cheers
Spart

[fetzerch]

Unfortunately, there is no call to query the backend protocol version.
We have to ask for the correct version by a connection attempt with a wrong version and get the correct version number as response.
This call is triggering that error message. It is harmless, we've checked the mythtv source code and there's no way to avoid it unfortunately.

Mythfrontend not not trigger such an error, because each version of mythfrontend only works with a single specific backend version.
But the XBMC PVR addon supports versions from 0.24-0.27.

Reference: http://www.mythtv.org/wiki/MYTH_PROTO_VE...rotocol%29

[sparticle]

Ah that's good to know. Thank you for your prompt attention.

Keep up the great work.

Just a thought: If you get the correct protocol version number back could you not write that to a config file on first use and then use that version in future.

Cheers
Spart

[nickr]

Until the backend changes version.

The way it is done is exactly how the myth developers intend it, so it is correct.

[sparticle]

Until the backend changes version.

The way it is done is exactly how the myth developers intend it, so it is correct.

From the MythTV Development Wiki!

http://www.mythtv.org/wiki/Category:Myth..._..._badly

Third Party Code that implements the Myth Protocol ... badly

These implementations support an unknown protocol version, and repeatedly guess at what version the backend wants to use, in order to force a connection without actually maintaining the code. This should be considered very dangerous behavior, and should not be used to connect to any production backend.

• libcmyth from mvpmc is a lightweight C client library which is also used by XBMC. It features livetv with epg, watching recordings and managing recordings.
  

Saying Hello

A Myth TV backend typically runs on port 6543 and the first thing you will need to do when you connect, is tell Myth the protocol version that you speak. This is done by sending the MYTH_PROTO_VERSION command. The only argument to this command is the version.

Here's the catch. If you send a version that is different than what the server is currently running, then it will reject you. When you are rejected, Myth does tell you what version you need to be at in order for the backend to talk to you. Do NOT claim support for a version that you do not understand, at a minimum you risk your application not working, at worst you destroy the users data and/or de-stabilise the backend.

[fetzerch]

This comment has been added to the MythTV wiki long ago.
The 'guessing of backend version' is referring to very early versions of the Library libcmyth.
Starting with MythTV 0.24 the backend prevents this guessing by a version token.

To clarify this: The XBMC PVR addon for MythTV has never been using a version of libcmyth that does
such kind of guessing. MythTV version specific differences are handled properly.

Therefore please simply just try to ignore this error message, or convince the MythTV developers
to implement a version of the MYTH_PROTO_VERSION that does not trigger this backend error message.

BTW: The idea you had with caching the version number, is possible - and could be implemented also to handle a backend version change.
Hopefully you understand that this has low prio for us, but it's open source, so 'patches welcome' :-)

[sparticle]

This comment has been added to the MythTV wiki long ago.
The 'guessing of backend version' is referring to very early versions of the Library libcmyth.
Starting with MythTV 0.24 the backend prevents this guessing by a version token.

To clarify this: The XBMC PVR addon for MythTV has never been using a version of libcmyth that does
such kind of guessing. MythTV version specific differences are handled properly.

Therefore please simply just try to ignore this error message, or convince the MythTV developers
to implement a version of the MYTH_PROTO_VERSION that does not trigger this backend error message.

BTW: The idea you had with caching the version number, is possible - and could be implemented also to handle a backend version change.
Hopefully you understand that this has low prio for us, but it's open source, so 'patches welcome' :-)

No worries. Just sharing what I found. Keep up the great work.

Many years ago in the dark ages of CCPM and BCPL and jarogate Sprites, I was a programmer. These days OOP is beyond me it seems

Cheers
Spart

[fetzerch]

No problem, it's just a bit annoying that this 'issue' pops up every now and then.
And we're in the unfortunate position that we cannot do much against that error message.