Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Belarathon]

On a Windows setup, I use a Harmony 650 remote to control my audio preamp, while I use a Microsoft MCE Model 1040 USB receiver to intercept the Harmony keypresses, and Intelliremote software to map remote key presses to correspond to JRiver media center. 

I installed Linux Mint, and then the latest beta of JRiver to check out theater mode...it seems quite usable.  Might someone suggest corresponding Linux analogs to the above setup?  I've found suitable software to manage the Harmony remote in Linux; beyond that, I'm unsure how to interface the remote with JRiver.

Thanks in advance,

Cary

[bob]

On a Windows setup, I use a Harmony 650 remote to control my audio preamp, while I use a Microsoft MCE Model 1040 USB receiver to intercept the Harmony keypresses, and Intelliremote software to map remote key presses to correspond to JRiver media center. 

I installed Linux Mint, and then the latest beta of JRiver to check out theater mode...it seems quite usable.  Might someone suggest corresponding Linux analogs to the above setup?  I've found suitable software to manage the Harmony remote in Linux; beyond that, I'm unsure how to interface the remote with JRiver.

Thanks in advance,

Cary

Not sure about this either, we've just started discussing it...

[JimH]

It might work by using Flirc as the IR receiver:
https://flirc.tv/more/flirc-usb

JohnT got it going with our Mac version.

[mwillems]

So I have two MCE remotes I used with windows and they both "work" in Linux with a bit of tweaking, but they work about 90% at this point in my tweaking.  They worked about 60% out of the box, but it took a bit of diagnostics to get to 90%, I anticipate getting to 100% with more time (I've only been working this for a few days).  You have to determine the driver situation with your remote, but I'll provide some of my notes on the current state of remote control of MC on Linux.  After performing this process almost all the buttons work, I'm just working on a few fringe buttons and struggling with one "main" button.

The first step is determining whether the linux kernel recognizes your remote as a "keyboard."  If so you're in luck and life will be relatively easy.  Both my MCE's worked as "keyboards."  The "easy" way to test this is to open MC in theater view and start pressing directional buttons, if the arrow keys work as expected, your remote is in the kernel and you're in luck.  A more definitive test is to open a terminal and type "show-key."  Then press remote buttons.  If you see keycodes showing up, your remote is recognized as a keyboard. 

If it's not recognized as a keyboard, you need to install and configure LIRC.  The Arch wiki article on LIRC is excellent and I recommend it if you find you have a LIRC remote.  I can't provide much advice on LIRC as both my remotes were "keyboards."

The next step (if you have a "keyboard" remote) is identifying keys that don't do what they're supposed to, and then remapping keys so that all your remote buttons work.  Use "ir-keytable" to list your devices, and "ir-keytable -t" to find out what keycodes each button on your remote is sending (you may need to install the ir-keytable first).  My advice is to redirect the output of "it-keytable -t" to a file, so you have them stored  and can modify them.  Once you have the list of scancodes from ir-keytable, use show-key to get keyboard codes of the keys you want to assign.  Once you have  file with the keycodes attached to the keys you want, you can remap the keys via script, but you need to re-run it every boot, so you can add it to your crontab or write a systemd service.

If you find that certain "standard" media keys (like stop) aren't working your desktop environment may be swallowing them to send to media players.  The problem is that MC isn't MPRIS-compliant so the DE has nowhere to send the keypresses (as I understand it).  You can edit your DE's hotkey settings to get it to ignore the keypresses and let them get to MC

Here are two links I found helpful in my quest
- https://www.mythtv.org/wiki/Remote_Control
- http://atterer.org/mythtv-xmbc-remote-control-without-lirc

And here's my script I run on boot:

Code: [Select]

#!/bin/bash
ir-keytable --write /home/michael/keymap --device /dev/input/event5

NOTES:
The remote device name is found in the output of "ir-keytable" with no flags.
The file keymap referenced in the script is essentially just the output of ir-keytable -t appropriately modified and looks like this:

Code: [Select]

scancode 0x800f0400 = KEY_NUMERIC_0 (0x200)
scancode 0x800f0401 = KEY_NUMERIC_1 (0x201)
scancode 0x800f0402 = KEY_NUMERIC_2 (0x202)
scancode 0x800f0403 = KEY_NUMERIC_3 (0x203)
scancode 0x800f0404 = KEY_NUMERIC_4 (0x204)
scancode 0x800f0405 = KEY_NUMERIC_5 (0x205)
scancode 0x800f0406 = KEY_NUMERIC_6 (0x206)
scancode 0x800f0407 = KEY_NUMERIC_7 (0x207)
scancode 0x800f0408 = KEY_NUMERIC_8 (0x208)
scancode 0x800f0409 = KEY_NUMERIC_9 (0x209)
scancode 0x800f040a = KEY_DELETE (0x6f)
scancode 0x800f040b = KEY_ENTER (0x1c)
scancode 0x800f040c = KEY_SLEEP (0x8e)
scancode 0x800f040d = KEY_MEDIA (0xe2)
scancode 0x800f040e = KEY_MUTE (0x71)
scancode 0x800f040f = KEY_INFO (0x166)
scancode 0x800f0410 = KEY_VOLUMEUP (0x73)
scancode 0x800f0411 = KEY_VOLUMEDOWN (0x72)
scancode 0x800f0412 = KEY_CHANNELUP (0x192)
scancode 0x800f0413 = KEY_CHANNELDOWN (0x193)
scancode 0x800f0414 = KEY_FASTFORWARD (0xd0)
scancode 0x800f0415 = KEY_REWIND (0xa8)
scancode 0x800f0416 = KEY_PLAY (0xcf)
scancode 0x800f0417 = KEY_RECORD (0xa7)
scancode 0x800f0418 = KEY_SPACE (0x20)
scancode 0x800f0419 = KEY_STOP (0x80)
scancode 0x800f041a = KEY_NEXT (0x197)
scancode 0x800f041b = KEY_PREVIOUS (0x19c)
scancode 0x800f041c = KEY_NUMERIC_POUND (0x20b)
scancode 0x800f041d = KEY_NUMERIC_STAR (0x20a)
scancode 0x800f041e = KEY_UP (0x67)
scancode 0x800f041f = KEY_DOWN (0x6c)
scancode 0x800f0420 = KEY_LEFT (0x69)
scancode 0x800f0421 = KEY_RIGHT (0x6a)
scancode 0x800f0422 = KEY_ENTER (0x1c)
scancode 0x800f0423 = KEY_BACKSPACE (0x7f)
scancode 0x800f0424 = KEY_DVD (0x185)
scancode 0x800f0425 = KEY_TUNER (0x182)
scancode 0x800f0426 = KEY_EPG (0x16d)
scancode 0x800f0427 = KEY_ZOOM (0x174)
scancode 0x800f0432 = KEY_MODE (0x175)
scancode 0x800f0433 = KEY_PRESENTATION (0x1a9)
scancode 0x800f0434 = KEY_EJECTCD (0xa1)
scancode 0x800f043a = KEY_BRIGHTNESSUP (0xe1)
scancode 0x800f0446 = KEY_TV (0x179)
scancode 0x800f0447 = KEY_AUDIO (0x188)
scancode 0x800f0448 = KEY_PVR (0x16e)
scancode 0x800f0449 = KEY_CAMERA (0xd4)
scancode 0x800f044a = KEY_VIDEO (0x189)
scancode 0x800f044c = KEY_LANGUAGE (0x170)
scancode 0x800f044d = KEY_TITLE (0x171)
scancode 0x800f044e = KEY_PRINT (0xd2)
scancode 0x800f0450 = KEY_RADIO (0x181)
scancode 0x800f045a = KEY_SUBTITLE (0x172)
scancode 0x800f045b = KEY_RED (0x18e)
scancode 0x800f045c = KEY_GREEN (0x18f)
scancode 0x800f045d = KEY_YELLOW (0x190)
scancode 0x800f045e = KEY_BLUE (0x191)
scancode 0x800f0465 = KEY_POWER2 (0x164)
scancode 0x800f046e = KEY_PLAYPAUSE (0xa4)
scancode 0x800f046f = KEY_PLAYER (0x183)
scancode 0x800f0480 = KEY_BRIGHTNESSDOWN (0xe0)
scancode 0x800f0481 = KEY_PLAYPAUSE (0xa4)

The left entry is the remotes scancode, the right hand is the description and hex code for the emulated key.

I know that's a lot of text, but it goes fairly quick once you get going.  I'll probably write a proper guide once I get my remotes to 100% (or if JRiver comes up with an easier integrated way!).  The main limitation of this method is that a given button can only be mapped to a single keypress, but fortunately most JRiver UI functionality is also mapped to single keypresses (backspace for back, space for play/pause, etc.)

[Belarathon]

Thanks everyone; especially mwillems for the wealth of information! 

[bob]

The MCE remote I have works without changing anything for the play button. No more.
The show-key command doesn't exist on wheezy or jessie.

This is what I get:
 ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
   Driver mceusb, table rc-rc6-mce
   Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
   Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
   Repeat delay = 500 ms, repeat period = 125 ms

ir-keytable  --write /home/bob/keymap --device /dev/input/event0
Wrote 63 keycode(s) to driver

So now I should be able to use the remote for other things, like stop, etc but that doesn't seem to work. I'm assuming the key is getting eaten by the DE but I don't see where to configure that in XFCE.

BTW, looked at the MPRIS stuff a bit.
It would be nice to see example code showing how to integrate that in c++ app at the low level that we are using.

[mwillems]

The MCE remote I have works without changing anything for the play button. No more.
The show-key command doesn't exist on wheezy or jessie.

I think debian calls it showkey and it's part of the kbd package: https://packages.debian.org/jessie/kbd

This is what I get:
 ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
   Driver mceusb, table rc-rc6-mce
   Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
   Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
   Repeat delay = 500 ms, repeat period = 125 ms

ir-keytable  --write /home/bob/keymap --device /dev/input/event0
Wrote 63 keycode(s) to driver

So now I should be able to use the remote for other things, like stop, etc but that doesn't seem to work. I'm assuming the key is getting eaten by the DE but I don't see where to configure that in XFCE.

Stop is the only major key I haven't been able to get working in Gnome (even after disabling gnome's handling of it), so I feel your pain.  There are a handful of other keys that I don't use that I haven't gotten working either, but I'm not in a hurry to deal with those.  All the other keys worked either after remapping (play, numbers, OK, the green button (sort of)) or once I figured out what the "real" key was in MC (i.e. space for play/pause, backspace for back, right for skip forward, left for skip backward, etc.).  Are there other keys you haven't been able to get working? 

If I were in control of the interface, I would be tempted to take the "easy way out" and associate a "standard" keyboard key with stop (as well as the other special media keys), and remap the remote to send those canonical keys.  So the same way play can be accomplished by sending the play command or pressing "space" with MC focused, stop could be accomplished by sending the stop command or pressing "s" if you take my point.  That way you could skip out on the media key question as it seems like it might be difficult to get those handled without DE integration.

BTW, looked at the MPRIS stuff a bit.
It would be nice to see example code showing how to integrate that in c++ app at the low level that we are using.

I assume you took a look at the spec (https://specifications.freedesktop.org/mpris-spec/latest/), which has some function calls, etc.  If you're looking for actual code to get a sense of what's involved, most of the players that implement it are FOSS, so you can have a look at their code to get a general idea.  Rythymbox has a fairly vanilla implementation, and this looks like a big chunk of it: https://github.com/GNOME/rhythmbox/blob/master/plugins/mpris/rb-mpris-plugin.c

[bob]

I think debian calls it showkey and it's part of the kbd package: https://packages.debian.org/jessie/kbd

Stop is the only major key I haven't been able to get working in Gnome (even after disabling gnome's handling of it), so I feel your pain.  There are a handful of other keys that I don't use that I haven't gotten working either, but I'm not in a hurry to deal with those.  All the other keys worked either after remapping (play, numbers, OK, the green button (sort of)) or once I figured out what the "real" key was in MC (i.e. space for play/pause, backspace for back, right for skip forward, left for skip backward, etc.).  Are there other keys you haven't been able to get working? 

If I were in control of the interface, I would be tempted to take the "easy way out" and associate a "standard" keyboard key with stop (as well as the other special media keys), and remap the remote to send those canonical keys.  So the same way play can be accomplished by sending the play command or pressing "space" with MC focused, stop could be accomplished by sending the stop command or pressing "s" if you take my point.  That way you could skip out on the media key question as it seems like it might be difficult to get those handled without DE integration.

I assume you took a look at the spec (https://specifications.freedesktop.org/mpris-spec/latest/), which has some function calls, etc.  If you're looking for actual code to get a sense of what's involved, most of the players that implement it are FOSS, so you can have a look at their code to get a general idea.  Rythymbox has a fairly vanilla implementation, and this looks like a big chunk of it: https://github.com/GNOME/rhythmbox/blob/master/plugins/mpris/rb-mpris-plugin.c

I didn't think rhythmbox was working at all with the MCE remote. I just noticed it does control volume with the arrows (not the volume control).
It's the version on wheezy so it might be too old.

We are capturing the X media keys in our keyboard code which seems to work for keyboards that have media keys. Not sure why the remote shouldn't just emulate those.
Here is the relevant chunk of code that does that mapping...

   

case VK_VOLUME_UP:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioRaiseVolume));          break;       case VK_VOLUME_DOWN:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioLowerVolume));          break;       case VK_VOLUME_MUTE:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioMute));          break;       case VK_MEDIA_NEXT_TRACK:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioNext));          break;       case VK_MEDIA_PREV_TRACK:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioPrev));          break;       case VK_MEDIA_PLAY_PAUSE:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioPlay)) || XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay,XF86XK_AudioPause));          break;       case VK_MEDIA_STOP:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioStop));

[mwillems]

Code: [Select]

[quote author=bob link=topic=107766.msg748316#msg748316 date=1478621943]
I didn't think rhythmbox was working at all with the MCE remote. I just noticed it does control volume with the arrows (not the volume control).
It's the version on wheezy so it might be too old.

MPRIS only reached it's modern form about three years ago, so it would be unlikely to be in the wheezy version (which is four years old now); it may not even be fully developed in the jessie version (two years old), but I haven't looked; my testing was with the current version.

We are capturing the X media keys in our keyboard code which seems to work for keyboards that have media keys. Not sure why the remote shouldn't just emulate those.
Here is the relevant chunk of code that does that mapping...

   

case VK_VOLUME_UP:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioRaiseVolume));          break;       case VK_VOLUME_DOWN:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioLowerVolume));          break;       case VK_VOLUME_MUTE:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioMute));          break;       case VK_MEDIA_NEXT_TRACK:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioNext));          break;       case VK_MEDIA_PREV_TRACK:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioPrev));          break;       case VK_MEDIA_PLAY_PAUSE:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioPlay)) || XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay,XF86XK_AudioPause));          break;       case VK_MEDIA_STOP:          bKeyPressed = XKeyPressed(aryKeyStates, XKeysymToKeycode(pDisplay, XF86XK_AudioStop));

It's interesting that your keyboard media keys work, the media keys on my keyboard do not work for me with JRiver and Gnome.  The volume keys do work, but they work because the DE (Gnome) is intercepting them and adjusting the system volume.  The volume buttons (keyboard or remote) don't change the MC volume at all, and none of the other keyboard media keys work.  I need to spend some more time testing various DE's to get a sense of what's eating the presses, but I can confirm that 1) Something is swallowing the media keys (probably Gnome in my case), and 2) they seem to get passed through just fine to MPRIS compatible players (i.e. rhythmbox, lollypop, banshee, etc.). 

That's probably because MPRIS is the main way that the "heavy" DEs (Gnome, KDE, Cinnamon) communicate with media players via dbus.  This makes sense as the DE's need to be able to handle (say) the volume keys outside of the mediaplayer context so they need them.  I think XFCE even uses MPRIS via dbus at this point, but I don't know for sure (e.g. it looks as though it might here: https://gist.github.com/jbonney/5743509).

So it seems like possible solutions are to:

1) To globally disable the DE's media key handling (which I haven't been able to do with Gnome, and would not be ideal for many users even if you could)
2) To expose an MPRIS control framework which would solve things for some major DEs, but I'm sure there are DEs that don't actually support MPRIS (LXDE, etc.), or
3) Pair media commands with "regular" keystrokes, which would require custom remote mapping, but would work in all DEs (no DE swallows the "s" key for example). I know this is how, for example, Myth TV handled a few troublesome media keys. 

Just thinking out loud.

[bob]

Thanks, I appreciate your thoughts...

The code from Rhythmbox seems to need gtk.
We aren't a gtk app (though we use the file chooser in places, it's basically tacked on only there).

[raymondjpg]

Not sure about this either, we've just started discussing it...

Personally I wouldn't even consider a media setup for a home theatre pc which does not have some facility for using an ir remote control. Linux is awkward enough already without the added complication of trying to shoehorn ir remote control capability on top of MC.

I cannot find any easy way of implementing ir remote capability through the MC setup. The Wiki says go to Tools > Options > Remote Control. There is no such option in my Linux Mint setup. While I can understand the reluctance of linux and its users to do anything easy and simple like implementing ir remote control, I cannot understand why MC has not implemented something for this that is quick and easy in its linux setup.

Have I missed something somewhere? I would purchase MC in a heartbeat if I could see an easy path to getting it to work  with a fully configurable consumer ir controlled device in Linux. That would include key remapping.

[JimH]

You might take a look at the Remotes page on our wiki.  There are several other ways you can do remote control.

I agree that IR control is important.  It's just a question of priorities.

[raymondjpg]

You might take a look at the Remotes page on our wiki.  There are several other ways you can do remote control.

I agree that IR control is important.  It's just a question of priorities.

So am I right that there is no option for configuring a Remote Control in Tools > Options > Remote Control in the Linux implementation?

The option is certainly there in a Windows 10 implementation with the exact same hardware.

[blgentry]

I think you are right.  I use MC almost exclusively on the Mac.  I have a couple of Linux installations too, but I mostly use the Mac.  I have not seen IR Remote support on either Mac or Linux.  I think it's a Windows MC only feature.

That being said, I have a pretty workable solution going with MC for Mac using the FLIRC adapter.  It requires configuration.  It took time to make it work correctly. But it does work. 

Brian.

[raymondjpg]

I think you are right.  I use MC almost exclusively on the Mac.  I have a couple of Linux installations too, but I mostly use the Mac.  I have not seen IR Remote support on either Mac or Linux.  I think it's a Windows MC only feature.

That being said, I have a pretty workable solution going with MC for Mac using the FLIRC adapter.  It requires configuration.  It took time to make it work correctly. But it does work. 

Brian.

If IR Remote support is indeed a Windows MC only feature, and I cannot see any other easy way to implement IR Remote support in Linux, then MC is not an option for me while I still have other (Windows) options available to me that can use madVR and LAV filters.

I did see the post about FLIRC and MAC, but MAC is not Linux, unless there is some way to implement the FLIRC/MAC combo in Linux. Even if there were it is to my mind an unsatisfactory workaround for a feature that I maintain should be seen as a standard install option for a MC in an HTPC.

[blgentry]

You seem to be very negative about this; almost like you are trying to talk yourself out of this solution.  Choose as you will of course.

FLIRC is universal.  It works on all platforms.  I'm relatively certain I could make MC with FLIRC on Linux work exactly like it works for me on Mac.

Good luck to you.

Brian.

[raymondjpg]

You seem to be very negative about this; almost like you are trying to talk yourself out of this solution.  Choose as you will of course.

FLIRC is universal.  It works on all platforms.  I'm relatively certain I could make MC with FLIRC on Linux work exactly like it works for me on Mac.

Good luck to you.

Brian.

I was mistaken, if FLIRC works on all platforms then it would be a possible solution for a Linux implementation of JRiver MC.

I am not trying to talk myself out of anything, I am always looking for alternatives to Windows!

[blgentry]

Don't get me wrong:  FLIRC requires quite a bit of configuration to get it right.  FLIRC "pretends" to be a USB keyboard.  So what the system sees are key presses.  So it's a two step process:

1) Map your remote control keys to keyboard keys using the FLIRC tool.  This gets saved into the FLIRC itself.
2) Configure MC to respond to the keyboard keys you have mapped above.

I think I mapped something like 10 or 12 keys that MC already understood, and then custom mapped another 5 or 6 for various things that MC did not do "out of the box".  Things like going directly to the Playing Now screen in Theater view.

This took me a few days of experimentation, on and off.  But the end result seems to work pretty well.

Brian.

[raymondjpg]

Don't get me wrong:  FLIRC requires quite a bit of configuration to get it right.  FLIRC "pretends" to be a USB keyboard.  So what the system sees are key presses.  So it's a two step process:

1) Map your remote control keys to keyboard keys using the FLIRC tool.  This gets saved into the FLIRC itself.
2) Configure MC to respond to the keyboard keys you have mapped above.

I think I mapped something like 10 or 12 keys that MC already understood, and then custom mapped another 5 or 6 for various things that MC did not do "out of the box".  Things like going directly to the Playing Now screen in Theater view.

This took me a few days of experimentation, on and off.  But the end result seems to work pretty well.

Brian.

Thanks for the tips. I did order a FLIRC Version 1 yesterday to test in Linux Mint. I saw that there was also a Version 2 available, but no indication anywhere as to what differences there may be between the two versions.