[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 
media player.

**** 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 
appropriate-for-what-you're-skipping amount.

More information about the mythtv-users mailing list