[mythtv-users] What major features are planned for 0.27?

Mark Greenwood fatgerman at gmail.com
Sat Nov 24 15:57:22 UTC 2012

On Saturday 24 Nov 2012 10:19:01 Michael T. Dean wrote:
> 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, ...

But that's exactly the point. The remote buttons don't send standard keyboard keys. The in-kernel mappings send KEY_PLAY, KEY_PAUSE, KEY_STOP, etc and not KEY_P, KEY_S, KEY_A etc. So there *is* a standard set of keys for a remote, just as there is for a keyboard. The point is that mythtv doesn't appear to recognise these 'multimedia' keys. If it did, most remotes would 'just work' without LIRC and without any special configuration. Plenty of applications now support these keys in addition to the old 'standard' keyboard shortcuts.

> 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 
> fish.

There's no standard remote design but there is a basic set of buttons that the majority of remotes can be expected to have, and as I've just pointed out, the in-kernel mappings ensure a standard set of keypresses. Given then that there is a standard, it could reasonably be expected that any application that supported the multimedia keycodes would behave in a predictable manner.

> 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.

Well, I understand that point. But if the GUI can't be navigated with just the basic arrow/OK/Back/Menu keys that nearly every remote has then the GUI needs a redesign. That's one of the reasons I like XBMC so much. Sure, the user can configure his extra butons to do clever things if he wants, but it shouldn't be *necessary*.

> 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 
> users.

Not upset, just having a discussion.

> Mike
> 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.

That's what I mean about keeping it sensible. Why can the default binding not accept KEY_OK *or* KEY_SELECT? There are only a finite number of buttons and only a small set of sensible uses for the main ones. It might not always work for every remote, but at the moment it doesn't work for *any* remote without setting up LIRC. 

> **** 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.  

Which is pretty much everybody. Remotes are laid out in VCR terms. If you look at the majority of the popular ones their layouts are very similar.

> 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.

How do you define an 'appropriate for what I'm watching amount'? I use FF to skip through commercials (because commercial flagging doesn't work very well for me). Commercial breaks aren't a standard length, so a 'skip forward x minutes' button is useless. 

I reiterate my point that, although you won't get a perfect default, you'll definitely get one that makes sense to everybody and works out of the box. If they decide to customize it later, they can. It makes a huge difference to a user's impression of a new application - 'it works pretty much and I can configure it the way I like it later' gives a positive impression, whereas 'it didn't work until I'd spent hours fiddling with config files' will put many people off before they've got started. The very first time I installed mythtv frontend it took me *two full days* to get LIRC working. The very first time I installed XBMC, the remote worked immediately, more or less. I now use XBMC. YMMV.

You're not going to please everybody, although I think the problem with mythtv sometimes is that it tries to do just that at the expense of common sense. A basic standard mapping of multimedia buttons to obvious VCR functions that everybody understands would ease the pain of getting the remote to work for a majority of new users, and that has to be good?


> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users

More information about the mythtv-users mailing list