raymond at wagnerrp
Feb 23, 2012, 10:55 AM
Post #14 of 83
(2254 views)
Permalink
|
|
Re: MythTV Frontend for Android released on Market
[In reply to]
|
|
On 2/23/2012 11:33, Ronald Frazier wrote:
> On Thu, Feb 23, 2012 at 11:10 AM, - -<fretinvin [at] gmail> 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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users
|
1
