Debugging, log keyboard entries seen by frontend?
Moderator: Forum Moderators
Re: Debugging, log keyboard entries seen by frontend?
Reviewing the remote control's lirc key bindings I see that chan+- are bound to PageUp and PageDown. So we can now navigate the EPG by days with 1,7 and page up/down with Chan+/Chan-. Numeric keys 3,9 still don't work though (which is what she who must be obeyed has always used). I would really like to be able to configure the system so that it matches the wiki.
Re: Debugging, log keyboard entries seen by frontend?
I think the answer is to swap the wife or get her retrained to use other keys
If all else fails you may be able to achieve what you want by adding some <triggerevent> to your theme in the definition for <guidegrid>
No idea if it will work but they would look something like this
That basically says if the '1' key is pressed send a "PAGEUP" action but only for the component that has the focus so in this case if <guidegrid> is focused then that substitution will take place everywhere else the default behaviour will be taken.
The <triggerevent> is somewhat discouraged from use since it can cause more confusion that it solves in some circumstances, for example in this case you could end up with some number keys working for the jump to channel feature and 1 & 7 doing something completely different
Just for the record here in the UK where we use sensible numeric only numbers like 123 for channel number the jump to channel feature works fine. There may be some confusion because it finds the nearest match so if you press 123 but that channel doesn't exist you may jump to 122 instead.
If all else fails you may be able to achieve what you want by adding some <triggerevent> to your theme in the definition for <guidegrid>
No idea if it will work but they would look something like this
Code: Select all
<triggerevent context="Global" action="PAGEUP">1</triggerevent>
<triggerevent context="Global" action="PAGEDOWN">7</triggerevent>
The <triggerevent> is somewhat discouraged from use since it can cause more confusion that it solves in some circumstances, for example in this case you could end up with some number keys working for the jump to channel feature and 1 & 7 doing something completely different
Just for the record here in the UK where we use sensible numeric only numbers like 123 for channel number the jump to channel feature works fine. There may be some confusion because it finds the nearest match so if you press 123 but that channel doesn't exist you may jump to 122 instead.
Re: Debugging, log keyboard entries seen by frontend?
Are you looking for 'PageUp' and 'Pagedown' ? They jump 7 channels on my 0.27 system.
I have those mapped to the channel up/channel down keys of my remote.
Phil
I have those mapped to the channel up/channel down keys of my remote.
Phil
Re: Debugging, log keyboard entries seen by frontend?
Let's say the guide is on channel 46 and channel 88 exists. You press 8, then 8, and then the EPG shifts so that the screen shows 88 in the middle (or thereabouts)?paulh wrote: ↑Mon Feb 05, 2018 10:38 amJust for the record here in the UK where we use sensible numeric only numbers like 123 for channel number the jump to channel feature works fine. There may be some confusion because it finds the nearest match so if you press 123 but that channel doesn't exist you may jump to 122 instead.
That just can't be compatible with the wiki description, since 4 of the 10 digits would be out of circulation.
I think what I'm going to do is edit the keybindings in the EPG section:
1. remove the current extra home, end bindings to keys 1,7
2. bind home/end instead to [,] which are vol+/- on the remote and not used in the EPG
3. tell the wife to use those instead of 1,4,7,9.
This
https://www.mythtv.org/wiki/Keybindings ... gram_Guide
really should changed to match the current release though!
Thanks everybody for your help.
Re: Debugging, log keyboard entries seen by frontend?
Only problem, it looks like that isn't possible, or at least isn't easy.
TV Frontend - remove the 1,7 bindings on volume up/down - no problem. At that point it would not allow those keys to be bound to anything. In fact it would not even register them from the remote or a keyboard in a highlighted "enter a key here" box. Luckily using "escape" to exit key bindings gives an option to cancel, which restored those values.
There are two categories for key bindings that matter here: TV Frontend and TV Playback. Both have volumeup volumedown.
Is there actually some place in the TV Frontend where the volume control can be used? TV Playback, sure, but in the EPG?
Regarding the "press keys to move to a channel in the EPG" it works like this:
2, 8 places the cursor one line above 28_1
7 places the cursor one line above 7_1
so far so good, but...
5,8 goes to the line above 29_1, nowhere near 58_1
Re: Debugging, log keyboard entries seen by frontend?
Upgraded to
2:29.0+fixes.20180202.9b7b962-0ubuntu0mythbuntu3
and it made no difference whatsoever. Sometimes it works, more often it doesn't. A navigation command that worked previously will generally not work after another has failed. Keyboard or remote, same deal. It turns out the few channels without sub channels (ie, 53) jump right to that channel in the EPG, whereas those with subchannels land on the channel above the first of the group with the same major channel. Ie, 5_1,5_2,6_1,6_2 enter "6" and it lands on 5_2. I'm going to go out on a limb here and guess that is a bug in the code where it assumes "6" means 6_0, and there is no such thing, so it ends up one channel above the first 6_x. Also navigation to channel 11 with "1" "1" has never, ever worked.
2:29.0+fixes.20180202.9b7b962-0ubuntu0mythbuntu3
and it made no difference whatsoever. Sometimes it works, more often it doesn't. A navigation command that worked previously will generally not work after another has failed. Keyboard or remote, same deal. It turns out the few channels without sub channels (ie, 53) jump right to that channel in the EPG, whereas those with subchannels land on the channel above the first of the group with the same major channel. Ie, 5_1,5_2,6_1,6_2 enter "6" and it lands on 5_2. I'm going to go out on a limb here and guess that is a bug in the code where it assumes "6" means 6_0, and there is no such thing, so it ends up one channel above the first 6_x. Also navigation to channel 11 with "1" "1" has never, ever worked.
- dizygotheca
- Developer
- Posts: 267
- Joined: Wed Sep 03, 2014 9:02 am
Re: Debugging, log keyboard entries seen by frontend?
That sounds consistent with the code comment I linked to earlier.Ie, 5_1,5_2,6_1,6_2 enter "6" and it lands on 5_2
Maybe the rationale is to distinguish 6_1 from 66_1 ?
It should accept separators (# - . _) so try 6#1
It does seem to get confused if you're not showing the "All Channels" group, ie the channel it wants to select isn't being displayed.
Multimedia keys such as Volume Up/Down are often problematic because of the keycodes they use.
The usual solution is to change your lirc config to send normal codes such as F10/F11/braces instead.
The keybinding screen can work with those.
Tv Frontend/VOLUME(UP|DOWN) bindings are probably used when EPG is shown during playback (and MythMusic?).
But you could live without it.
I don't see a problem with re-instating the TvFrontend/PAGE(UP|DOWN) bindings.
However, if you then bind them to 1,7 then you'll have 2 numeric keys that page & 8 that jump (somewhere).
A better solution would be to get the volume key working.