[mythtv-users] What major features are planned for 0.27?
Michael T. Dean
mtdean at thirdcontact.com
Sat Nov 24 15:19:01 UTC 2012
On 11/24/2012 08:48 AM, Mark Greenwood wrote:
> On Friday 23 Nov 2012 22:37:34 Michael T. Dean wrote:
>> On 11/23/2012 10:02 PM, Preston Crow wrote:
>>> On 11/23/12 21:58, Michael T. Dean wrote:
>>>> On 11/21/2012 10:10 AM, Mark Greenwood wrote:
>>>>> One thing that could be contributed though, and I don't know how
>>>>> easy/hard this would be but with pointers I'd be prepared to look into
>>>>> it, would be to make mythtv understand the multimedia keycodes sent by
>>>>> IR remotes that are handled by the kernel's devinput interface (eg
>>>>> KEY_PLAY, KEY_FASTFORWARD etc). Xbmc understands these natively and
>>>>> means I didn't have to go through the trauma of setting up lirc.
>>>> Pretty sure you just need to use mythfrontend's Edit Keys to set what
>>>> you want each to do.
>>> Yes, but the point is that this is something that should just work
>>> without doing anything. There should be good default settings for all
>>> those keycodes already. (This hasn't impacted me, but it sounds like
>>> a simple and obvious improvement.)
>> Of course, you do understand that there are both TV Playback|PLAY, and
>> TV Playback|PAUSE (which is toggle play/pause).
>> It's neither simple, nor obvious, to me which one the play button on
>> Mark's remote should send... And the play button is the simplest of the
>> multimedia ones... Does fast forward do a Global|RIGHT or TV
>> Playback|SEEKFFWD or TV Playback|FFWDSTICKY or even TV Playback|JUMPFFWD?
> Actually it's only complicated because mythtv makes things complicated by having too many choices. XBMC seems to take a much more pragmatic view. In a logical, simple world the Play key starts playback, the Pause key pauses and unpauses, and the Fast Forward button fast forwards - just like on any off-the-shelf PVR system made in the last 30 years, because people understand that. It's obvious what the default settings should be, and people can still customize if they want to.
> The keys on my remote are already mapped by the kernel's ir-keytable interface - no need for LIRC. The mapping means that whatever your remote, the kernel sends something sensible - KEY_PLAY when you press Play, KEY_FASTFORWARD for FF etc, so assigning them to functions the average PVR should have should be simple. Of course there will alays be some that need tweaking by the user, but a sensible set of defaults that would work with any remote of this type wouldn't be hard to come up with. LIRC is pretty old hat these days, the latest kernel has mappings for most of the common remotes already.
Yes, and anyone who uses the built-in-to-the-kernel key mappings for the
remote buttons then ends up changing the key bindings in /every/ single
application on their system so that the remote button that sends an A
(or KEY_A) does the appropriate thing in that application*** (and has to
learn their custom keymaps/can't discuss default bindings/...). And, to
make it worse, for users with multiple frontends, using kernel key
mappings for the remote means customizing every single mythfrontend on
every single system (not to mention also customizing xine, mplayer, vlc,
xmms, xmms2, audacious, ...
So, you either configure LIRC so that it sends per-application messages
based on the remote button pressed (and have one configuration file that
can work on every single system in your house and can be put in place
after a distro upgrade/re-install) or you configure every single
application on every single system with every single distro install.
The only reason keyboards "just work" is because there's a
generally-standard 98+ key design for any given locale that has all the
most-appropriate characters. Until someone makes for a standard remote
design and everyone just uses it--and every single application is
rewritten to expect/support it--remotes are a whole different kettle of
And, I haven't even gotten into the discussion about how MythTV is /not/
just a video playback application--there are a lot of contexts in which
actions may occur--and any button that's unusable in any given context
is wasted, but which buttons you map to which actions in each context
depends--especially-on how many and which buttons you have. So, what
should the fast forward button do in the schedule editor? If you say
"nothing," remember that answer presumes that the remote has enough
non-numeric/non-VCR buttons**** to actually handle the other required
buttons for MythTV navigation/control.
Again, though, if you're really upset, just wait for the key bindings
themes and make one that you feel is appropriate and share it with other
*** While the user could just learn that A does TV
Playback|ADJUSTSTRETCH in MythTV (so I hope they actually use time
stretch) and does ResetAmp in xine (so I hope they actually use the
software amplification in xine and need to reset it) and does toggle
subtitle alignment in MPlayer and (TTBOMK) does nothing in xmms and ...
using the per-application defaults for remote buttons requires the user
to re-learn the remote for every single application. And, further, it
is likely to lead to the same button doing different things in different
applications or even being unused by some applications. Of course, we
won't even mention how much complaining the people who have remotes with
different buttons from yours are going to do when they don't have the
MythTV-won't-work-without-it Global/SELECT binding because you felt it
should be mapped to KEY_SELECT and their remote has no Select, but has a
KEY_OK that they think should be Global/SELECT in MythTV.
Again, my assertion is that without a standard remote control layout,
it's impossible to just Do The Right Thing with remote buttons--even the
simple ones. What seems simple is extremely complex when you look at
the number, type, and designs of various remotes people are using and
the fact that MythTV is much more than MPlayer or xine--it's not just a
**** And, yes, I really mean "VCR" buttons, and not DVR buttons. IMHO,
fast forward and rewind are only actions performed by people who are
thinking in VCR terms. DVRs are random-access, so there's no need to
fast forward, and I can't think of a situation where you'd get a benefit
from fast forwarding versus just skipping some
More information about the mythtv-users