Remote "All supported" considered harmful

[prl]

I'm beginning to think that the "All supported" setting for the T series remote control code selection is a misfeature.

• There are occasional reports (e.g. here and here) of T series boxes responding to unexpected remote controls.
  I have two remotes for other devices that map to button presses to the T series when "All supported" is set for the PVR's remote code set. One is a HDMI Switch (noname, but uses LenKing LKV501 codes) and a Digitel TV (sold by Beyonwiz/Dealspace).
• Even for Beyonwiz-supplied remotes, "All supported" doesn't work correctly if you use a T2 or T4 remote code set that isn't the device's "native" code set (or if you use a T3 remote on a T2 or T4, or a T42 or T4 remote on a T3).
  If you use a "non-native" Beyonwiz code set in the remote and the PVR uses "All supported", when the PVR is turned on from standby by a recording timer and then shuts down at the end of the timer without the remote being used, the PVR can only be switched on using a remote that sends the POWER code from the "native" code set for the device.

Is there a good reason for not removing "All supported" and have the factory default codeset for each device set to that device's "native" setting.

[MrQuade]

I think fixing it to the default codeset would be a sensible idea.

This has started to become a minor problem now that the T series IR drivers are responding to a wider number of device IDs.

[IanSav]

Hi Prl,

Perhaps a more conservative move might be to make the default remote control code the native remote control code and not "All supported". However, leave the "All supported" available in the menu for any who want or need it.

Regards,
Ian.

[prl]

Sorry, Ian. I disagree. I really think that "All supported" is so broken it should go as a user setting.

There is one problem in eliminating "All supported" completely, though, and that is that it is probably still needed in the startup wizards.

If you use a non-standard code set for a device and do a USB upgrade, the upgrade doesn't know that you use a non-standard code set, and then the remote you normally use for the device won't work to get you through the setup wizard, not even to restore your defaults (which will normally contain the correct remote code setting).

Also, the timeout on the "Is this remote OK?" popup should probably be extended. It doesn't really allow enough time for you to select the code on the PVR, then change the code set on the remote, and then press DOWN, OK to confirm the change. This is a problem currently, too, but it's probably not noticed because people normally only change between "All supported" and a specific code set, or vice versa. They can currently be accommodated by changing the remote code first when going from "All supported" to a specific code, and by changing the code afterwards to go from a specific code to "All supported". If the user is too rushed to switch between specific codes, they can always go via "All supported". But those workarounds disappear if "All supported" goes.

[IanSav]

Hi Prl,

With "All supported" I like the fact that I can pick up the nearest Beyonwiz remote control, T2, T3 or T4, or IR remote control tablet and know that it will always work on the Beyonwiz unit in the room. I will loose that convenience if the option is removed.

Regards,
Ian.

[prl]

I'd be happy to go for retaining "All supported" if it meant "all remotes that are in the onscreen list of supported remotes", which seems to be the only really useful definition of it. Like that, it could even remain the default.

However, I don't know if that can be implemented on the standard input device drivers.

IMO "All supported" as it is now is simply broken. In my test setup, I have to be careful not to allow the test boxes (which I keep as "All supported") to "see" the TV's remote.

[IanSav]

Hi Prl,

Perhaps whatever was changed to introduce the problem should be backed out until the problem can be addressed.

Regards,
Ian.

[prl]

...
Perhaps whatever was changed to introduce the problem should be backed out until the problem can be addressed.
...

The two instances of problems in the latest firmware are simply due to remotes being added to the set of remotes recognised by the low-level input device driver. It doesn't make much sense to back out of thoose particular changes. For example, the problems I have with the Hisense TV remote predate the 2016-04-19 firmware, and I have no idea how far back you'd have to go before that stopped being a problem. I doubt that the upstream source is likely to stop adding them, so it would be a choice between accepting the new remotes and keeping up to date with other changes, stopping updates (which may not be feasible), or maintaining a special version of the input drivers that only contains the relevant remotes (I can't see that as very attractive, either).

[IanSav]

Hi Prl,

I find it hard to believe that the new drivers are allowing through so many code sets without any masking, selection, mapping or discrimination coding. It is okay for the drivers to allow a large range of code sets but then the firmware should be selecting the appropriate code sets with which to respond. Open slather code execution seems fraught with danger.

Regards,
Ian.

[prl]

...
I find it hard to believe that the new drivers are allowing through so many code sets without any masking, selection, mapping or discrimination coding. It is okay for the drivers to allow a large range of code sets but then the firmware should be selecting the appropriate code sets with which to respond.

I don't know if there's a better method, but the method currently used writes the numeric strings in the following table to /proc/stb/ir/rc/type to recognise the corresponding remote code sets:

Code: Select all

modelist = [
	("0", _("All supported")),
	("5", _("Beyonwiz T3 (0xABCD)")),
	("10", _("Beyonwiz T3 alternate (0xAE97)")),
	("6", _("Beyonwiz (0x02F2)")),
	("7", _("Beyonwiz (0x02F3)")),
	("8", _("Beyonwiz (0x02F4)")),
	("3", _("HDx (0x0933)")),
]

The table is in Plugins/SystemPlugins/RemoteControlCode/plugin.py.

Code "0" seems to be the only option here to allow multiple code sets, and then it's everything that's known about.

Open slather code execution seems fraught with danger. ...

My point exactly.

[MrQuade]

PeterU should have access to the list. He knew immediately what the problem was when we discovered that code set 0x99 was the source of that first incident report with the HiFi device.

It might not be a huge list of extra code sets (1 or 2 extra sets maybe?) that are allowed through, so it may not be a giant issue.

I do agree with prl though that if the code set is not exposed as a setting in the options in the GUI anywhere, then the Wiz should not respond to it at all, even when set to "All supported". Those secret code sets are after all not exactly " supported" as such.