Hi,
Upgrading osmc to the last version today, my usb remote is no more working. This is a standard USB infrared device which was working for years until this upgrade:
osmc@osmc:~$ lsusb
Bus 001 Device 007: ID 1784:0008 TopSeed Technology Corp. eHome Infrared Transceiver
…
The first time (ans last time ?) I’ve upgrade using the gui at start, is there any chance to downgrade and get it working again ?
Thanks
Have a search
To fix eHome you will just want to remove the decoder module blacklist
Alternatively you can set up an LIRC remote profile
Sam
Thanks for your answer but how to “remove the decoder module blacklist”.
Set up an LIRC profile ??? For a device bought specifically for kodi (xbmc at that time) several years ago and working with no issues… really disapointed
You may wish to contact the manufacturer then. We can’t guarantee support for third party hardware.
Search because I have covered exactly how to revert these changes numerous times over the last few days.
Solved ! Going to myOSMC -> remote and setting explicitely rc6 remote, it works. I’m not following osmc changes and this perhaps is not predictable but this is not a nice user experience to answer yes (with your remote :-)) to an update question and having your media device working worse than before.
Unfortunately sometimes it is not possible to make improvements without altering the way software is configured or works - previously the RC6 kernel decoder was enabled by default when it shouldn’t be, this would cause duplicate key presses for anyone trying to use the rc6 profile in My OSMC remotes, so this was definitely a bug, and a bug that has been reported many times by many users.
A side effect of this bug was that some RC6 remotes such as yours would “just work” without even being configured, and some people may have relied upon this lucky accident. Unfortunately there is absolutely no way for us to know who might have relied on this, therefore when we fix the bug your remote stops working until you correctly select your remote as RC6 in My OSMC remotes.
This is the nature of software in general - every major Kodi release tends to break something for someone because the way Kodi works keeps changing and evolving, configuration options change, get added or removed, etc. For any update you have to allow for the fact that the way something that you rely on works may change and this may affect you. This is the price for forward progress.
If you don’t want to have to deal with this, don’t update. And when you do eventually update, be prepared for a small learning curve for features that may have changed and a visit to the forum if you need any help with any changes.
Don’t want to enter a long discussion (I’m an IT engineer with a long experience including several years in support :-)) but not upgrading software today is not an option as components depends more and more on others and having one working force you to get others updated … Please be carefull to prevent us to loose time only to get things working as before.
But I understand your point. Anyway thanks for your support and your work.
We made these proposed changes available for testing almost a month before release
Unfortunately we cannot test all hardware combinations, but this change was intentional and resolves an issue where users experienced duplicate remote presses.
Re-enabling the remote was not an arduous task. I can understand the inconvenience of things breaking, but the fix was quite quick, and easy here, as we are still supporting your remotes, but doing so a little differently.
The problem is not that you made these changes. The problem is that for anyone who doesn’t read these forums regularly, there was no warning of them. This sort of change, which you clearly knew would present itself to an end user as their remote not working, should absolutely have been communicated to users with the install. Either before the update(preferably) or after the update was installed, by popping a window that gives users a short explanation and either the option to re-enable the rc6 remote right from there or instructions for how to do so through the normal menu system. The fact that this was not done is simply unacceptable from a user experience perspective.
You did not configure your remote via My OSMC and as such it worked by luck (a fallback), but this caused more adverse affects for those that did configure a remote via OSMC’s recommended method, the remotes module.
Thus, I fixed the duplicate press bug affecting a couple of thousand users, and so far have only had a single digit number of users experiencing broken remote support. The needs of the many outweigh the needs of the few, particularly when the alleged, cataclysmic breakage that ensued can be rectified by simply selecting a remote profile in My OSMC or deleting the blacklist file.
You’ve joined a few minutes ago to make this complaint, and I suspect we won’t see you post again, until something else goes wrong. That’s fine – but you should be aware that these changes were made available for testing almost one month ago. Further – this was highlighted on the updates release notes. If you do not read Blog - OSMC for each monthly update, you should not install OSMC updates. We simply cannot convey information if users do not chose to read it, and the proposition to present a dialog for each change is preposterous. Certainly when you consider how many changes are made each month, and the fact that other users have different interests in changes. For example, with your remote, you would not be interested in CEC changes, but another user may have been greatly invested and relying upon CEC.
With that said, some users have unfortunately been conditioned to expect their remotes which worked with the internal decoder to keep working despite not configuring a proper remote profile. I will, next update, re-enable the decoder by default but make it changeable via My OSMC → Remotes, as the more apt users who have configured a remote profile and are experiencing duplicate presses seem more able, and willing, to make a brief change to make the overall user experience for others better.
I genuinely thought users were using My OSMC → Remotes. That’s why we put it there. I can’t test every hardware combination, and people’s different (or lack of) configurations.
At the very least then you should display the patch notes to users before updates are installed. Not everyone has time to read your blog. I work as a software developer, these are just extremely basic things that you should be doing. If I did something like this I would spend the day after release being bitched at by my boss.
Well you would be bitched at by your boss because your boss pays you to do a proper job for him. So unless you are paying @sam_nazarko a salary and therefore becoming his boss stop bitching at him 
The point is that unless he wants future issues similar to this, where users are essentially left in the dark, he should improve his communications with his users.
I will take your suggestions on board. We do plan to put release notes on screen in future updates. I do suppose then that if we have informed them right on their TV screen, there will not be much justification in quibbling
Delivering release notes to the user is more complex than you may think, but it is being worked on.
Sam
Are you quite finished lecturing us on how the OSMC project should be run ? Perhaps you would like to try your hand at managing a project of this size with this number of users, in your spare time ? No ?
I was going to let it go, but you like I could definitely lecture you more.
No thanks. If you’re unhappy with OSMC I suggest you find an alternative.