[mythtv-users] MythTV Frontend for Android released on Market

[Raymond Wagner]

On 2/23/2012 11:33, Ronald Frazier wrote:
> On Thu, Feb 23, 2012 at 11:10 AM, - -<fretinvin at gmail.com>  wrote:
>> I would like to have it supporting multiple backend versions but I don't
>> know how. Is there a way? The only thing I have seen regarding this is that
>> you should not "probe" the backend for versions... Is there a way to tell
>> the the backend to be backwards-compatible?
> No, as I recall neither the frontend nor backend are forward or
> backward compatible. They must always match protocol versions exactly.
> Other myth-compatible software maintains compatability by supporting
> multiple protocols and then using whichever one is supported by the
> backend.
>
> You said not to probe for backend versions, but that's not really
> true. The guide you link to says that when you say hello by telling it
> your protocol version, it will reject you but tell you what version it
> does support. You can then reconnect using a different protocol IF YOU
> HAVE CODED SUPPORT FOR THAT PROTOCOL. The main point there is, don't
> just assume the protocol is similar enough and say that you support
> version X+1 when you really only truly support version X.
>
> I used to run a couple of hauppauge media MVP devices, and they had
> myth compatible firmware that ran on them. As I recall, that's exactly
> how they handled supporting multiple version. They would connect to
> myth and identify as supporting a specific version and then reconnect
> using the appropriate supported protocol once it knew what the backend
> was using.

Exactly.  The correct version response from the backend is there 
specifically for that reason.  Just because the first party protocol 
libraries choose not to support more than a protocol version at a time 
does not mean third party libraries are denied from doing so.  The 
`mythbox` plugin for XBMC is a good example of how to do this properly.  
They have a base version and communication class they use to attempt 
connecting.  If there is a mismatch, they have an array of further 
protocol versions implemented as subclasses to that base, with modified 
commands and data processing to correctly communicate with the backend.  
If there is not a class supporting the protocol version returned by the 
backend, it aborts.

On the other hand, `mythbox` only provides the content lists for XBMC, 
while XBMC has its own internal support for streaming from the backend, 
provided by libcmyth.  Libcmyth is an example of how not to do things, 
attempting some bogus version number, and then parroting back whatever 
version the backend responds with.  Just prior to the 0.24 release, I 
added an identifier token to the version check.  The correct version is 
returned upon an error, but the token is not.  The client must send the 
proper token matched to that version.

In theory, that would mean any client needs to be properly updated for 
the new version.  In practice, the client could just be recompiled with 
the new token, blind to whatever protocol changes incurred it.  Or the 
client could take a user selectable value.  Or the client could pull the 
proper tokens from some web service, or scrape the protocol 
documentation on the wiki itself.  The token check was simply added to 
make bypassing the version check more of an annoyance, and hopefully 
suggest to any developer otherwise wanting to do so that it is a bad 
idea.  There is no good reason to do so.  Someone might claim it is 
useful for development purposes, but for that, there is a compile flag 
in MythTV that disables the version check entirely.