[mythtv] [mythtv-commits] Ticket #8877: Add unique token check to protocol handshake

Chris Adams rocket at extremelan.net
Wed Sep 8 01:36:52 UTC 2010


On Tue, Sep 7, 2010 at 6:21 PM, Stuart Morgan <stuart at tase.co.uk> wrote:
> On Tuesday 07 Sep 2010 03:38:48 Chris Adams wrote:
>> Despite staggering efforts of developers the frontend continues to lag
>> behind the competition in some important ways. Most notably,
>> mythfrontend hasn't received years of work on flashy animated themes
>
> Something tells me that even if I copied the most popular XMBC theme exactly
> (http://www.mythtv.org/wiki/MythUI_Demo_Theme) you'd still find fault.
>
> FWIW, I'll enable the movement animation support which has been included in
> libmythui from day one after the 0.24 release.
>
>> and isn't compatible with as many video formats and containers.
>
> Not true, in fact I'd suggest the opposite might even be true, but importantly
> which codecs/containers being used in anything but the most obscure contexts
> are unsupported?. We also have full working bluray playback support in trunk
> thus 0.24 (including playback direct from encrypted discs) which last I
> checked wasn't supported by anyone else except in patches.
>
> What I think you're really missing however is that none of the 'alternative'
> frontends offer a tenth of the functionality of mythfrontend. Not even close.
> Features like MHEG, timestretch etc make mythfrontend one of the most capable
> video player out there and probably the easiest since everything is exposed
> via the gui, no command line switches required. What other 'alternative'
> frontend offers full access to the entire range of functionality offered by
> the backend and it's associated apps (mythtranscode, mythcommflag), which one
> covers scheduling features as thoroughly?
>
> It's frankly staggering that you suggest the frontend be dropped because in
> your perception others are already better in a couple of respects (I'll give
> you one), when the others are inferior in many, many respects. It would take
> more work to include every mythfrontend feature into XBMC than it would to
> write a couple of themes for MythTV.
>
> The patch Raymond proposed would deprive no-one of an alternative, it would
> simply ensure that those alternatives work properly and means the backend is
> better able to protect users data from clients which have the potential to
> destroy data and disrupt functionality. The issue is not that we're actively
> discouraging alternative frontends but that many of them are poorly written
> and their maintainers too lazy to support a protocol which changes maybe half
> a dozen times a year at the most.
>
> P.S. It may not have been your intent, but your post was a huge insult to the
> developers who have invested years of work in mythfrontend.
> --
> Stuart Morgan

Stuart (and everyone else)

There was no insult intended.
I wouldn't dare suggest anyone working on anything instead of what
they choose to work on. Sorry for the confusion.
What I was saying is that in my own setup I've eschewed mythfrontend
because its theme isn't as visceral as confluence in XBMC. But with
animation support it'll get more appealing themes over the coming
years. In the meantime XBMC is nice and visceral so my myth menu uses
it in place of MythVideo.

And you're right about the amount of functionality in the frontend -
it's amazingly functional and hackable.

Personally I like mythfrontend but you're right, I'm far too fussy.
But that doesn't mean I want anyone else to do my bidding - what right
do I have to dictate anyone's use of their free time? I'm not an
idiot.

I just want to not be denied the choice, and this patch denies me said
choice, hence the complaint about the patch. You might think it
doesn't, but I'm concerned about version skew and developer
motivation. It denies me the choice because it prevents me using an
up-to-date mythbackend with an up-to-date frontend (that happens to
have a slightly out-of-date protocol implementation). And all that'll
happen in the future is alternative clients will allow the token to be
set in a config file and go right on using their old version logic.

This patch isn't solving the problem. It's driving away yet more
people who seek alternatives.


More information about the mythtv-dev mailing list