[mythtv-users] What major features are planned for 0.27?
fatgerman at gmail.com
Sat Nov 24 17:59:11 UTC 2012
On Saturday 24 Nov 2012 12:13:34 Michael T. Dean wrote:
> 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?
Because the button that sends 'KEY_PLAY' has a big PLAY symbol on it. What else is it going to send? The button that sends KEY_FASTFORWARD is the Fast Forward button. Just like on a keyboard, the button with 'A' on it sends 'KEY_A'. It's no different, the application simply has to understand an extended set of keys and map sensible defaults in the default keybinding. I really think, without wanting to offend, that you're overcomplicating the issue in your own mind. The button with the big arrow on it is the PLAY button, that is KEY_PLAY, and is mapped to 'Play' in every appplication I can find except mythtv.
> 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.
As it currently stands, I have to edit LIRC *and* MythTV Edit Keys. Without LIRC at least I only have one thing to arse about with.
> >> 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
That has never worked for me. Mythtv has never recognised any multimedia key on my remote. The only ones that work are the arrow keys because the kernel generates the standard arrow key button codes for those buttons. Which means I then have to stop LIRC from also generating those keys or I get double keypresses. And then auto-repeat doesn't work. Other apps have no trouble with any of this.
> >> **** 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.
I reckon you're in a minority there. Most people don't know or care about the difference between a VCR and a DVR. TV is linear, shows run from start to end. The ability to jump around randomly is of little use to most people.
> >> 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.
But can your mates also operate it when you chuck them the remote and say 'find something to watch'? I bet I could do the skip faster on my machine than I could on yours. I don't want another learning curve, I just want a remote that behaves how a remote is supposed to behave. And maybe because I'm over 40 I expect it to behave like a VCR, but so do my family, freinds, and their teenage children. I think the amount of configurations possible in mythtv is catering for a tiny minority and making things worse for the majority in the process.
> > 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.
But that's all you need! By all means customize the other stuff later but at least you'll have a remote that basically works when you install the software.
> > 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.
I completely disagree. If nothing works, the user won't know where to start and will likely get pissed off and install XBMC instead. The only reason I got LIRC to work was that I'm a total geek who refuses to be defeated by technology :) Any normal sane person would have thrown it out long before. If I'd had basic buttons working I could at least have *used* the thing and taken some time over solving the problem, knowing that it was a 'nice-to-have' instead of an essential thing that had to be solved before I could start using my new DVR computer.
> 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.
What you're suggesting is that it is better to have a flaky peice of middleware that has global configuration files, user configuration files, and hardware configuration files which then maps onto a frontend that has yet another set of configurations, than to have a default set of keys that work without any configuration at all. You have too much time on your hands :)
(BTW Mythbutnu Control Centre is the reason my first experience with LIRC was two days of screaming frustration. It's OK when you understand how it works, but for someone who had never used LIRC before the fact it didn't even set up my hardare.conf correctly, and then the default mappings it created for my Haupauge remote contained keys my remote didn't even have, and the 3 (or was it 4) places I had to find and edit config files .... You might well be right that an abstraction layer is a good thing, but when that abstraction layer is LIRC and the config interface is Mytbuntu Control Centre I'd rather eat my remote than use it.)
> 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
Play/Pause/FF/RW/Arrows/OK/Menu/Back/Stop/numbers is ALL you need to keep 80% of users happy. That's all my TiVo box had (when I had one) and I think they're quite popular. Show me a remote that doesn't have keys that can sensibly be mapped to that and that don't generate KEY_PLAY/KEY_PAUSE/KEY_FASTFORWARD etc by default, and I'll show you a pink rotating elephant.
> Therefore, the specific remote layout must be considered when
> creating mappings of key bindings--just like it's done in the kernel for
> 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).
LIRC only makes sense in the context of a machine that does more than operate as a mythtv frontend. If you're setting it up as a media centre is meant to used (tucked away behind the TV with no mouse or keyboard) then mappings for multiple apps is not necessary.
Your themes idea makes a lot of sense, but the default theme, I think, should incorporate the basic keys that most people will use, so they can be saved the torment.
> 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).
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users