[mythtv] A need for advanced player settings

[Kyle Rose]

> It might offend a lot of people to say it, but 99.9% of users are not going to
> know what appropriate values for such a setting should be or even understand
> it's purpose.

You're right. But the logical consequence is to force users like me
onto another platform because I don't want to keep compiling custom
code to get my HTPC to operate like it should with perfectly
reasonable hardware and perfectly reasonable content.

> The other half descend on
> forums, mailing lists and the bug tracker to report that MythTV won't play
> their files and everyone's time will be wasted to finally establish that the
> user chose bad values for a buffer setting.

This is why I'm arguing that you should make it possible to change the
setting without making it easy. I would be happy submitting a patch
for an override coming from the settings table but without an
associated menu in the front end, if that satisfies your desire to
lock down the platform.

> There is a very good reason why we've spent the last two years trying to
> eliminate many of the settings we already had and it's not just about making
> MythTV easier to configure.

And if it worked I would have no complaint.

> I'm almost sympathetic with Apple's attempt to
> lock down their platforms to improve the user experience for a majority of
> their customers.

When you lock down MythTV to an associated content store—the only way
you will entirely eliminate compatibility problems—you will
concurrently lose what makes Myth so appealing to users like me: its
openness.

>  If you make something configurable then it will be used
> inappropriately, even if you attempt to hide that setting deep inside a hidden
> config file somewhere (someone will just advertise it's existence on their
> blog or mailing list complete with incorrect instructions for it's use).

The Linux kernel folks came up with a middle ground that involved the
notion of tainting: when someone loads a non-GPL module, for instance,
there are loud messages in each oops indicating that the kernel is
tainted by something closed-source or otherwise unsupported. Their
response was not to lock down the module API so nothing outside the
source tree could be compiled against the kernel.

> Those with the technical competence to understand this buffering will likely
> also be those who are comfortable building from source and patching source-
> code and therefore it's probably best left that way until we have a proper
> fix.

I don't want to maintain my own patch set. Like all animals, I have
evolved to conserve energy and therefore I am lazy. It's that simple.
:-)