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

[Michael T. Dean]

On 11/24/2012 10:57 AM, Mark Greenwood wrote:
> 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*.

I know there's a standard mapping.  It's useful for a few "exists on 
almost every remote" buttons (numbers and VCR buttons), but what about 
all the other keys--such as the one labeled A on my remote that sends 
KEY_A...  Users still have to map them, and doing so with a view to what 
other keys they have on their remote allows them to structure the remote 
to be most useful in the most contexts.

Also, just because someone on the kernel team feels that some button on 
my remote should send KEY_COFFEE (whatever that is?) and a different one 
should send KEY_QUESTION (?), what makes you think that's the correct 
thing for that button to send?  It's only correct when there's a 
separate logical mapping from that "hardware" key to a useful function 
in the application in use--so there has to be some mapping somewhere--be 
it in LIRC or MythTV Edit Keys.

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

It can, but then the user with both OK and Select buttons on their 
remote (me), gets a stupid mapping.

>   There are only a finite number of buttons and only a small set of sensible uses for the main ones.

And a /much/ larger combination of specifically which buttons are 
grouped together on various remotes.

>   It might not always work for every remote, but at the moment it doesn't work for *any* remote without setting up LIRC.


No, it /does/ work without setting up LIRC...  Just map the keys/buttons 
in Edit Keys.  Go in there, find the action to which you want to map it, 
select Bind Key (or whatever) and hit the Play button on your remote 
(that sends KEY_PLAY) and, voila!  No LIRC needed for those who don't 
understand why LIRC (and abstraction of configuration from specific 
hardware) is A Good Thing.  (Keys with keycodes above 256 
notwithstanding, due to a limitation in X--though those work fine with 
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.

Yes, and I've mapped my VCR keys to DVR actions because I use my remote 
with a DVR.

>> 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 guarantee I can use skips and seeks to get to the start of the show 
after a commercial break faster than you can use FFWD to do so.

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

No, a few VCR buttons and the number keys work out of the box.  Most of 
the rest of the remote doesn't.

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

And if nothing works, the user looks to see how to configure it 
properly.  If it "mostly works", but some desired 
functionality/buttons/... don't work, users think that it's a broken 
application and uninstall it.  Only those users who are serious about 
having a nice DVR will get it working and stick with it.

Again, though, LIRC isn't necessary, so "have to install LIRC, which is 
confusing" is not a valid argument.

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

But, still, the /right/ approach is to have a database of specific 
remotes (with knowledge of their available buttons) and of mappings 
(such as LIRC mappings--or, eventually, MythTV key bindings themes) and 
then have some configuration thing (such as MythTV Control Center, which 
is used by Ubuntu) configure *everything* (meaning every key on the 
remote) with a proper default for *that* remote.

That will please everybody.

There can never be just one sane default mapping for remotes--because 
there's no one sane default layout/number of buttons/set of buttons for 
remotes.  Therefore, the specific remote layout must be considered when 
creating mappings of key bindings--just like it's done in the kernel for 
keyboards.

This is my only point.  This is why I think that remote mappings without 
knowledge of remote layouts make little sense--and why I have a plan for 
key bindings themes that allow for a sane "default" mapping that takes 
into account the specific layout of the remote (and without need for 
LIRC, but still allowing LIRC for those of us who appreciate it).  IMHO, 
this is much better than a stopgap that creates bindings for some few 
remote buttons (and leaves others useless), and may make configuration 
more difficult in the future (right now our key lists are complex 
enough, so I'd prefer not to make them more complex before we get the 
right solution in place).

Mike