I am still using a Harmony Elite remote with my setup (… and dreading the day it finally packs in
), and since the August update for my Vero V I had noticed that the Menu button was not bringing up the Context menu (I managed to get it to appear once or twice, against 100+ presses where is didn’t work).
I had written it off as possible a problem with an Emby plugin I use.
But last night, I decided to investigate.
I set the Menu action up on my remote touch screen, and it still didn’t work.
I then dug out my Vero V remote (and replaced the battery, as I never use it!) and low-and-behold the menu button worked every single press ![]()
So I know it isn’t my Emby plugin causing the problem, but something seems to have changed with the August update and my remote.
The remote is connected as a Bluetooth device as “Harmony Keyboard”, and this has worked fine for years (Vero4k+ and now Vero V).
Any ideas as to what may have happened to stop the Menu function?
I will be honest and say that this is a “minor irritation” and nothing critical - it has taken me two months to bother to look in to it more
But it would be nice to resolve it, if possible.
There have been no changes to my Harmony Remote (and probably never will be).
I don’t have a clue what could be going on here, nor a BT remote to test it with, but if you’re comfortable with ssh’ing into your box you might try…
kodi-send -a toggledebug
tail -f ~/.kodi/temp/kodi.log | grep -B 1 'HandleKey'
At this point you would press the menu button on your remote to see if it is being registered in Kodi and with what. Each button press should come back with two lines of information. Once your done checking the response you can hold down ctrl and press “c” to exit the tail command and then send that first command again to turn debug logging back off.
Thanks for the commands darwindesign ![]()
I’ve done a small test, and basically the menu button on my Harmony remote shows nothing when pressed
Press Menu on Harmony Remote
<nada>
Press Menu on Vero V Remote
2025-10-24 06:16:20.052 T:2840 debug <general>: Keyboard: scancode: 0xb4, sym: 0x29 (rightparen), unicode: 0x29, modifier: 0x0
2025-10-24 06:16:20.052 T:2840 debug <general>: HandleKey: rightbracket (0xf029) pressed, window 10000, action is ContextMenu
Press Menu on Harmony Remote
<nada>
Press Menu on Vero V Remote
2025-10-24 06:17:40.804 T:2840 debug <general>: Keyboard: scancode: 0xb4, sym: 0x29 (rightparen), unicode: 0x29, modifier: 0x0
2025-10-24 06:17:40.805 T:2840 debug <general>: HandleKey: rightbracket (0xf029) pressed, window 10106, action is Back
Press Info on Harmony Remote
2025-10-24 06:17:43.821 T:2840 debug <general>: Keyboard: scancode: 0x17, sym: 0x69 (i), unicode: 0x69, modifier: 0x0
2025-10-24 06:17:43.821 T:2840 debug <general>: HandleKey: i (0xf049) pressed, window 10000, action is info
So the Harmony Menu button is showing nothing, but the Info button does register (and does the correct action - just a sanity check).
I dug in to the Kodi.log file directly afterwards, and couldn’t see anything else around the time of pressing the Menu button on the Harmony remote.
So basically I just need to get my remote to send a “rightbracket” key stroke? That should be easy enough to configure manually by adding a generic keyboard to the Action in Harmony and then select the key for the button.
That might work, but I’m a bit curious why it stopped working. Having the OSMC remotes send that particular key is a workaround to get it to work across all languages. Typically a Kodi remote would use a “c” key press for the context menu but there are some keyboard languages where that is a dead key. Is your keyboard set to something other than english in settings>system>input>hardware keyboard layouts>?
To go one step forward at the terminal you can install evtest (sudo apt-get install evtest) then run evtest to see what response you get back from that menu key.
Well, that was interesting …
I went in to the settings>system>input>hardware keyboard layouts> and it correctly showed “English (UK)”. While in that area and looking at other settings, I accidentally altered the OSMC remote mapping file from “osmc” to “os” (due to the key strokes and the Cancel button not doing what I expected!), so I used the “Restore defaults” in that section to make sure it was set to what was expected.
And then when I went back to the main screen, the context menu was working ![]()
I rebooted, and it was still working.
So either my keyboard layout was in a “Schrödinger’s Cat” state and needed me to examine what it was set to for it to actually become that setting, or the “Reset defaults” action I did triggered something beyond just the OSMC remote?
Either way, I am a happy camper now and can mark TV episodes as Watched, etc.
Did you change the keyboard language to something else and then back again? I could see how doing that would set anew how the OS interprets your remote and fix something that got corrupted in that regard. Resetting the OSMC remote settings for sure wouldn’t have had an impact here as it does nothing other than manipulate keymapping layouts which would not have kept that key from registering in the debug log.
Glad to hear it. Doesn’t that BT remote support long-press (holding down the button for a couple seconds to get a secondary action)? If so with the OSMC special keymap enabled you should be able to just hold down the play button to toggle watched status. Bringing up the context menu and navigating for that gets old pretty quick in my experience.
No, I didn’t touch/alter/change the keyboard language setting at all: I just went to that section and saw it was set to “English (UK)”.
I did go in to the “Peripherals”, “Driver settings” & “Configure attached controllers”, but only made a change under the Peripherals section as noted above.
The long press works nicely in the TV Series view to toggle the Watched status, but doesn’t appear to work in the “Recently added episodes” view at the top menu. It just flickers, but nothing happens. Should it work there too?
I wouldn’t have thought that anything would have changed just by going into that settings screen. The only thing I can think that would change at all would be a fresh saving of Kodi’s settings that gets triggered by going into the settings and then back out again. As this would be an OS level “whatever” issue I guess it will just have to stay a mystery as to the exact cause.
On the home screen play long-press triggers a library update. If memory serves the togglewatched actionid only works in library views which the home screen/widgets is not. It has been years now since I made the OSMC keymap and did these kinds of tests so if you feel inclined you could try mapping it to the home window and see if it works. Just make sure that your mapping it in home and not global as that wouldn’t work for a different reason.
I thought I would compare my OSMC backup settings from overnight with the previous night’s backup, and there appears to be no changes at all (in relevant sections) ![]()
The datestamps of guisettings.xml and profiles.xml has changed, but they are exactly the same content. And the estuary skin settings.xml is only different because it decided to write out its settings in a different order: same settings, different order in the xml.
I then ran the debug commands again and pressed the “menu” button, and it was interesting ![]()
2025-10-25 10:31:01.728 T:2907 debug <general>: LIRC: - NEW 171 0 KEY_TITLE linux-input-layer (KEY_TITLE)
2025-10-25 10:31:01.747 T:2816 debug <general>: HandleKey: yellow (0xe5) pressed, window 10000, action is ContextMenu
So I take it the Harmony is programmed to use something very different for the menu button?
Likely just a case where Kodi logs the key name wrong. Some input does this, I’ve no clue why. When this happens it makes keymapping a bit more of a pain as you need to use other methods to figure out what keys you are mapping. Assuming you haven’t customized anything relevant, if that remote had actually sent out yellow it would have opened the music library. Also, I’ve not seen the Harmony automatically set a button to something queer to how it is labeled on the remote. My guess is that remote is actually sending “menu” as I believe the only buttons that are default mapped to the context menu are menu, c, and long-press enter and select (actually the long-press action are default Kodi mapped but that is changed on devices running the OSMC remote keymap).
Isn’t LIRC the Linux Infrared Remote Control daemon?
Does this imply that this code is being sent as IR rather than BT? If so, then “environmental factors” may have been interfering with that single button action getting through, and maybe I nudged my IR blasters around or something.
I was just reading about LIRC being used to get old MCE remotes working with Kodi, so I wonder if the Harmony OSMC 4k device (the latest model they have defined) template has a weird mishmash of commands going on: some BT, some IR.
I may experiment with pressing EVERY programmed key on the Harmony to see the debug code, and then try programming BT Keyboard equivalent commands to see if it is more reliable.
Update
I have experimented pressing every key, and this is the result
Harmony Remote - Down
2025-10-25 12:37:04.523 T:2816 debug <general>: Keyboard: scancode: 0x6c, sym: 0x112 (down), unicode: 0x00, modifier: 0x0
2025-10-25 12:37:04.523 T:2816 debug <general>: HandleKey: down (0xf081) pressed, window 10000, action is Down
--
Harmony Remote - Left
2025-10-25 12:37:07.976 T:2816 debug <general>: Keyboard: scancode: 0x69, sym: 0x114 (left), unicode: 0x00, modifier: 0x0
2025-10-25 12:37:07.977 T:2816 debug <general>: HandleKey: left (0xf082) pressed, window 10000, action is Left
--
Harmony Remote - Right
2025-10-25 12:37:12.492 T:2816 debug <general>: Keyboard: scancode: 0x6a, sym: 0x113 (right), unicode: 0x00, modifier: 0x0
2025-10-25 12:37:12.493 T:2816 debug <general>: HandleKey: right (0xf083) pressed, window 10000, action is Right
--
Harmony Remote - Up
2025-10-25 12:37:14.159 T:2816 debug <general>: Keyboard: scancode: 0x67, sym: 0x111 (up), unicode: 0x00, modifier: 0x0
2025-10-25 12:37:14.159 T:2816 debug <general>: HandleKey: up (0xf080) pressed, window 10000, action is Up
--
Harmony Remote - Home
2025-10-25 12:37:30.900 T:2907 debug <general>: LIRC: - NEW 66 0 KEY_HOME linux-input-layer (KEY_HOME)
2025-10-25 12:37:30.926 T:2816 debug <general>: HandleKey: percent (0x25) pressed, window 10000, action is PreviousMenu
--
Harmony Remote - Info
2025-10-25 12:37:42.723 T:2816 debug <general>: Keyboard: scancode: 0x17, sym: 0x69 (i), unicode: 0x69, modifier: 0x0
2025-10-25 12:37:42.723 T:2816 debug <general>: HandleKey: i (0xf049) pressed, window 10000, action is info
--
Harmony Remote - Menu
2025-10-25 12:38:15.653 T:2907 debug <general>: LIRC: - NEW 171 0 KEY_TITLE linux-input-layer (KEY_TITLE)
2025-10-25 12:38:15.671 T:2816 debug <general>: HandleKey: yellow (0xe5) pressed, window 10000, action is ContextMenu
--
Harmony Remote - OK
2025-10-25 12:38:36.336 T:2816 debug <general>: Keyboard: scancode: 0x1c, sym: 0x0d (enter), unicode: 0x0d, modifier: 0x0
2025-10-25 12:38:36.337 T:2816 debug <general>: HandleKey: return (0xf00d) pressed, window 10000, action is Select
--
Harmony Remote - Pause
2025-10-25 12:38:48.056 T:2816 debug <general>: Keyboard: scancode: 0x39, sym: 0x20 (space), unicode: 0x20, modifier: 0x0
2025-10-25 12:38:48.056 T:2816 debug <general>: HandleKey: space (0xf020) pressed, window 10000, action is Pause
--
Harmony Remote - Play
2025-10-25 12:38:55.611 T:2816 debug <general>: Keyboard: scancode: 0x19, sym: 0x70 (p), unicode: 0x70, modifier: 0x0
2025-10-25 12:38:55.611 T:2816 debug <general>: HandleKey: p (0xf050) pressed, window 10000, action is PlayPause
--
Harmony Remote - Return
2025-10-25 12:39:02.754 T:2816 debug <general>: Keyboard: scancode: 0xe, sym: 0x08 (backspace), unicode: 0x08, modifier: 0x0
2025-10-25 12:39:02.754 T:2816 debug <general>: HandleKey: backspace (0xf008) pressed, window 10000, action is Back
--
Harmony Remote - SkipBack
2025-10-25 12:39:10.364 T:2816 debug <general>: Keyboard: scancode: 0x13, sym: 0x72 (r), unicode: 0x72, modifier: 0x0
2025-10-25 12:39:10.364 T:2816 debug <general>: HandleKey: r (0xf052) pressed, window 10000, action is Rewind
--
Harmony Remote - SkipForward
2025-10-25 12:39:11.791 T:2816 debug <general>: Keyboard: scancode: 0x21, sym: 0x66 (f), unicode: 0x66, modifier: 0x0
2025-10-25 12:39:11.792 T:2816 debug <general>: HandleKey: f (0xf046) pressed, window 10000, action is FastForward
--
Harmony Remote - Stop
2025-10-25 12:39:14.344 T:2816 debug <general>: Keyboard: scancode: 0x2d, sym: 0x78 (x), unicode: 0x78, modifier: 0x0
2025-10-25 12:39:14.344 T:2816 debug <general>: HandleKey: x (0xf058) pressed, window 10000, action is Stop
--
Harmony Remote - ChannelDown
2025-10-25 12:46:08.486 T:2816 debug <general>: Keyboard: scancode: 0x6d, sym: 0x119 (pagedown), unicode: 0x00, modifier: 0x0
2025-10-25 12:46:08.486 T:2816 debug <general>: HandleKey: pagedown (0xf085) pressed, window 10000, action is PageDown
--
Harmony Remote - ChannelUp
2025-10-25 12:46:09.433 T:2816 debug <general>: Keyboard: scancode: 0x68, sym: 0x118 (pageup), unicode: 0x00, modifier: 0x0
2025-10-25 12:46:09.438 T:2816 debug <general>: HandleKey: pageup (0xf084) pressed, window 10000, action is PageUp
It looks like just the Menu and Home functions are sent as IR, while everything else is BT.
I have re-programmed the Menu key to now send BT ‘c’ via the keyboard, and it works flawlessly.
I wish I had worked this out years ago rather than when my Harmony is in its twilight of life, but hey-ho. I was dupped by the fact that since it needed the BT keyboard setup therefore that everything was BT, not realising that some of the commands may still be sending as IR ![]()
And thanks @darwindesign for sending me down the right rabbit hole ![]()
