yawor

The configuration on the device is updated automatically every time you record or delete a key or change something in advanced options. Yes, restoring the backup (using load configuration options in the GUI) overwrites previous config stored on the device.

Well, Flirc is a keyboard, so maybe WMC thinks it doesn't need to open an on-screen keyboard, because it got the event from the "real" one (to the system there's no difference between real keyboard event and Flirc events). But this is only a theory. I've never used WMC.

Hi, What TV box is that? I'm trying to decode the signal data you've used by I don't recognise the protocol. Is the Flirc IR window pointing in the TV box's direction? Flirc has really good IR receiver but the IR transmitter is not very powerful.

@Bob Sutton you can name your config files any way you want. The name of the config file doesn't matter to Flirc. It is only a backup of the config. Flirc doesn't load its config from a file as the config is stored ON the device. To make it clear: save configuration is used to backup Flirc's internal config area to a file and load configuration is used to restore Flirc's internal config area from a previously saved file. You don't need to save the config for Flirc to work. The "invalid length" has nothing to do with config files. Can you send me your log with that message?

@Bob Sutton my question was about that specific remote which @Cubytus asked about. I don't understand why do you need to teach your remote something. For example here's my usual approach with my universal remotes: 1. If this is a multi-device universal remote, select a device slot I want to use with Flirc. 2. Select some device like a Samsung TV (or other type of equipment; the idea is this has to be something you don't actually have in your home) and program it on the selected device slot. 3. With Flirc GUI test how many keys I'm able to record, if they are all unique, if they work on each key press and if the key repeat works. Not all hardware has need to use all keys on the remote so some keys may be inactive. If I'm not happy with that setup then I format Flirc and go back to point 2 and select different device. 4. After finding a device setup on the remote Flirc is happy with, I start programming each key on the remote with specific functions (for example in Kodi controller) or key combinations (in full keyboard controller - not all functions are predefined in the Kodi controller, but it's easy to find default keyboard controls on Kodi wiki pages). 5. Some functions in Kodi don't have a key combination assigned in the default keyboard control mappings. If you need to control such function directly with Flirc, you need to modify your Kodi keyboard mappings (search for keyboard.xml on Kodi wiki pages) and include added key combinations in your Flirc config using Flirc GUI. This is a most generic instruction which should work with any universal remote. With Harmony remotes you also have predefined Flirc harmony profiles. I'm using a setup for some Samsung TV model (uses NECx2 protocol) for few years now. I've used it with original Flirc (in clear plastic) and I'm using it with new Flirc gen2 (metal one).

No, unfortunately it wouldn't solve anything, because hashing algorithm doesn't work properly with XMP signal (protocol used by Dreambox). This means that even if you have two different frames captured in the debug, they can still produce the same hash. Like I've already said, this protocol is really ugly to work with.

Well, I thought that my response was enough as for me the other questions were based on the assumption of using the Dreambox remote. As the Dreambox remote is not supported, any of the features you've proposed wouldn't help. Anyway: A1: It's not possible to create hash yourself. The hashing algorithm is proprietary. A2: This is a nice idea and has been proposed few times by some people (myself included). There are plans to implement this (but it would still not help with Dreambox). A3: I understand what would you like to achieve with this but I don't think it would be possible to do. Please understand that Flirc tries to be as universal as possible when it comes to supported remotes/different IR protocols, but some of the protocols are so complicated that adding support for them would make the algorithm much more complicated and slower that all the other supported remotes would also suffer from the slow down.

Hi, Sorry to disappoint you but the protocol used by the Dreambox remotes (XMP) is not supported yet. It's really hard to tell when (if ever) it's going to be supported as it's a really nasty one. Besides sending 2 or 3 different frames on every single key press, it also uses 4-bit encoding scheme - it encodes each 4 bits of the data as one of 16 different burst/gap lengths.

The post is hollow, but this doesn't impede the heat transfer in any significant way. The post itself may have less heat capacity, than a solid block, but the whole case acts as a heat sink and heat spreader so the heat from the CPU is dissipated quickly enough.

@Cubytus is this an universal remote? Can it be programmed to control different devices? If yes, then you can try reprogram it for some other type of hardware and then try using it with Flirc.

Try playing with display scaling in Windows settings.

Flirc doesn't operate on scan codes, but on HID codes for keyboard and consumer tables (consumer table is currently limited to 1 byte only, so codes only up to 255 - some specific codes above 255 are also supported by other means), because Flirc is a HID device. HID keyboards know nothing about scan codes. Scan codes are generated from received HID codes by the operating system according to keyboard layout settings (for keyboard table) or other drivers (for multimedia/consumer table).

Controllers are interchangeable. They only group different keys together, but Flirc doesn't store information about selected controller. So you can record some keys from one controller and some keys from another. Most controllers (like Kodi for example) are just a collection of pre-configured, ready to use keyboard shortcuts and you can actually achieve the same functionality using full keyboard controller if you know those shortcuts. Flirc doesn't deal with key codes. It works on a lower level and maps your IR signals to USB HID codes. It's up to your OS to interpret them and emit key codes to applications (which is done by the keyboard layout selection in most OSes). You can use flirc_util for more precise control as there is a "record_api" command which takes two 1-byte values (decimal) as a key definition. But you need to enter HID codes, not key codes. I like to use this http://www.freebsddiary.org/APC/usb_hid_usages.php to get my HID codes. Scroll down to table 7 (keyboard). Bear in mind that information on that page is only true for US QWERTY and other compatible layouts. HID codes are assigned to a physical key location on the keyboard, not to a specific letter or symbol. So key "Y" on QWERTY will have the same HID code as key "Z" on QWERTZ.

@orion just edit the /etc/apt/sources.list and replace debian with ubuntu and buster with with xenial in the Flirc repo address. Then run apt-get update and apt-get install flirc again.

Thanks for sharing. This is really good info. It may help us troubleshoot in the future. BTW the new Apple's FaceID also uses IR projector. This may apply also to other mobile face or eye scanning technologies. I wonder if/how they interfere with Flirc. I've just checked on my Huawei P10 Lite but I need to point the screen at the Flirc right next to it. I wonder if cameras with laser focus could also affect it. Unfortunately P10 Lite doesn't have one and my Nexus 6P has broken down.

It's not about specific distribution, but about the CPU architecture. You need version for ARM CPU. You can try to downloading and running this package http://apt.flirc.tv/arch/raspbian/binary/flirc-3.9.6.raspbian.tar.gz on libreelec. Unless it's missing some libraries there's a chance that it'll work.

It should be also possible to use thermal paste, but not too much. Just a tiny bean on the center of the CPU. No need to smear it over the CPU, it'll get squished by the case. I'd use just a tiny drop of good, silver based paste like Arctic Silver 5. Another possibility is an elastomeric thermal pad, which is used on many box CPU heatsinks (a gray rubber-like pad). Something like that: https://www.3m.com/3M/en_US/company-us/all-3m-products/~/3M-Thermally-Conductive-Silicone-Interface-Pad-5519/?N=5002385+3294001841&rt=rud

@grkblood13 you're using wrong URL for downloading the deb package manually. Try wget --content-disposition https://packagecloud.io/Flirc/repo/packages/ubuntu/xenial/flirc_3.9.12_amd64.deb/download.deb The packages are all the same so the one for xenial should still work. To fix the apt source, check /etc/apt/sources.list.d. One of the files there should contain a deb source added by the script. Edit that file and change the release code (artful) to xenial. Then run apt-get update and apt-install flirc again.

Well, Flirc can't compete with EventGhost feature-wise, that's for sure. EG is far superior for complex scenarios. But it's also a Windows only solution and requires a software install and a lot of playing with configuration to achieve acceptable controlling scheme. On the other hand, Flirc can work without any supporting software on the host system. All that's needed is support for USB keyboards so it works with probably any operation system. It's also portable as the configuration is stored on the device itself. There's nothing stopping you from using EG with Flirc. You can use Flirc native keyboard capabilities and just augment it with EG for some more advanced features. Then the basic features would still work even when the EG exit due to some error.

Let me first clarify the issue from your first post. If I understand correctly, for example the P key (for play/pause) works every second press of the button. At least that's what I've understood from "alternate key presses". If I misunderstood this then could you elaborate what exactly the issue is? If I understood this correctly, then recording the button twice should work. Did you clear the configuration before testing recording pause twice?

Flirc SE is a gen1 device.

With MCE remote you need to record each button twice, because the signal alternates between button presses.

Unfortunately there's not. It's directly connected to the USB port's power pins. You can use an electrical tape for example, to dampen the LED's brightness. Cut out a square and tape it over the LED. You can also use multiple layers to make it even dimmer.

It's updated on the fly. The save/load configuration options are for backing up and restoring the config from a file.

I'm not 100% sure but I think that the default play button for the built-in Kodi profile uses multimedia Play key, not the P key. That's why you don't see it. You can safely reprogram it to use the P key instead. Set up your Harmony to use the Flirc/Kodi profile and then open up the Flirc GUI, go to the Full keyboard controller and click on the P in the app. When asked, press the Play/Pause button on your remote. The logic is that the user configuration overwrites the built-in profiles, so you can reassign single or multiple buttons from the provided Flirc/* profiles.