MCE RC6 IR receivers shortcomings (2 Viewers)

[CyberSimian]

If IRSS didn't receive or understand the SIRC command (ie. if your amp happened to be located on the opposite side of the room from the PC's MCE-compatible receiver, or IRSS didn't support SIRC), you'd experience exactly the same symptoms as you have with the "MS driver".

Thank you, I understand this now. So IRSS is not "watertight", but it is better than the Microsoft driver.

This raises the question of whether MP should be using IRSS by default. You are better qualified to judge this than I am, but I think that my problem is sufficiently rare that it is probably not worth making a change. Also, this problem is now identified, and the solution known. So this can be explained to anyone else who encounters this problem in the future.

One-for-All is a very popular brand in Europe, and their remotes are generally cheaper than those from Logitech Harmony. So it is a shame that they suffer from this problem. But they are certainly not alone. The first universal remote that I used with WMC was an MX850 made by Universal Remote Control of America. The MX850 is an advanced remote control, but it too suffers from the same problem as the One-for-All.

(For completeness I will test the "General HID" support later today, and post the results.)

-- from CyberSimian in the UK

 

[mm1352000]

This raises the question of whether MP should be using IRSS by default.

I don't think a reasonable judgement could be made until you've tried MP's latest HID handler. For all we know, the HID handler may also work.

One-for-All is a very popular brand...

Sure. Short of shifting to low-level decoding like IRSS - which is quite complex - I don't think there is any solution. In theory the problem could be resolved by adding a time condition (ie. Has it been more that X ms since the last button-press? If yes => this must be a new press, even if the toggle bit hasn't flipped.) to the existing toggle bit handling in the de-bounce processing. However as you know that code is out of our control.

 

[CyberSimian]

I don't think a reasonable judgement could be made until you've tried MP's latest HID handler. For all we know, the HID handler may also work.

I have now tested the "Generic HID" handler (as implemented in MP 1.12). The test regime was as before.

From observing MP's responses to the button-presses:

-- "Generic HID" with the One-for-All remote suffers from the same problem as "Microsoft MCE".
-- "Generic HID" with the Harmony remote works correctly.

From looking at the logs (attached below), the button-presses received are similar to MCE, in that the second press of the GUIDE button (action(3)) is missing from the log for the One-for-All remote, but present for the Harmony remote.

Aside: I notice that the button presses to exit from MP (UP, LEFT, LEFT) are also not present in the "Generic HID" logs. Is this expected behaviour for "Generic HID"? Their absence from the log file makes following the user's actions more difficult.

-- from CyberSimian in the UK

 

[mm1352000]

Thanks
I pretty much expected this result, because it seems that every method of acquiring input from a MCE-compatible receiver - except the method that IRSS uses - goes through "the MS driver".

Aside: I notice that the button presses to exit from MP (UP, LEFT, LEFT) are also not present in the "Generic HID" logs. Is this expected behaviour for "Generic HID"? Their absence from the log file makes following the user's actions more difficult.

The MS driver converts those button-presses into events that are indistinguishable from keyboard keystrokes. So, those buttons work in any program (even when the program doesn't support MCE-compatible remote controls)... but the trade-off is as you've described.

 

[CyberSimian]

I pretty much expected this result, because it seems that every method of acquiring input from a MCE-compatible receiver - except the method that IRSS uses - goes through "the MS driver".

Thank you for taking the time to look at the IR signals and decode them. I have been irritated by this problem since I first started using WMC in 2009, so it is good to have a definitive answer.

I now have to choose between using an MCE RC6 receiver with IRSS, or the Ortek/Hama. Since the MCE RC6 receiver will still suffer from the occasional malfunction on wake from sleep or hibernation, I am probably going to choose the Ortek/Hama for long-term use. I am not a fan of the Ortek/Hama remote, but it is possible to load the Ortek/Hama definitions into a One-for-All remote, and I would expect (not checked this yet) that the Harmony has definitions for the Ortek/Hama too.

Out of the box, the Ortek/Hama has some deficiencies, but it is possible to overcome these by using an AutoHotKey script (which I have included with the Ortek/Hama config file that I provided in another thread). The only remaining disadvantage of the Ortek/Hama is the rather too-bright LED that flashes when a signal is received. But one cannot have everything...

-- from CyberSimian in the UK

 

[mm1352000]

Thank you for taking the time to look at the IR signals and decode them. I have been irritated by this problem since I first started using WMC in 2009, so it is good to have a definitive answer.

No problem. The situation interested me, so I was also keen to understand what was going on.

Since the MCE RC6 receiver will still suffer from the occasional malfunction on wake from sleep or hibernation...

I'm not sure if that's a given. IRSS closes device handles before suspend and re-opens them on resume, so you shouldn't have a problem with IRSS... unless the issue is lower down the stack.

 

[mm1352000]

The only remaining disadvantage of the Ortek/Hama is the rather too-bright LED that flashes when a signal is received.

Surely nothing a strategically positioned piece of tape couldn't fix?
...or would tape also block the receiver?

 

[CyberSimian]

I'm not sure if that's a given. IRSS closes device handles before suspend and re-opens them on resume, so you shouldn't have a problem with IRSS... unless the issue is lower down the stack.

Interesting... it had not occurred to me that IRSS might solve the IR receiver malfunction too.

My custom is to exit MP before sleeping or hibernating the system. When the system wakes, MP is not running, and the IR receiver malfunction occurs at the Windows desktop (before MP is involved). If IRSS is running as a service, that would be active on wake. I guess the only way to see if IRSS does solve this problem is to try it for a few weeks.

Surely nothing a strategically positioned piece of tape couldn't fix? ...or would tape also block the receiver?

The IR receiver is a tiny "box" (37mm x 20mm x 11mm) made from red translucent plastic. It is the small end of the box (20mm x 11mm) that faces the room and contains the receiver and LED. The box is also glued shut, so not possible to gain access to the internals without breaking it. The bright red LED is offputting initially, but after a while one ceases to notice it.

-- from CyberSimian in the UK

 

[mm1352000]

When the system wakes, MP is not running, and the IR receiver malfunction occurs at the Windows desktop (before MP is involved).

Ahhh, yes - but MPTray (ie. the thing that listens for the green button and starts MP) would be running, would it not? ...and if yes, that would be similar if not equivalent to having MP running.

If IRSS is running as a service, that would be active on wake.

Correct... though like I said in my previous reply, the device handles are closed and re-opened. So the service is essentially just a place-holder, waiting for the system to resume.

I guess the only way to see if IRSS does solve this problem is to try it for a few weeks.

Yeah, agreed.

The IR receiver is a tiny "box"...

Wow, that is small... though I s'pose it makes sense given that it doesn't support transmission (blasting).

 

[CyberSimian]

I guess the only way to see if IRSS does solve this problem is to try it for a few weeks.

Yeah, agreed.

Since the beginning of 2016, I have been using the Ortek/Hama IR receiver. For most of that time I have also used the Ortek/Hama remote, so that I could develop and test the MP config for it, and the AutoHotKey script. But since that is not a universal remote, I had to use a second remote to control the volume on my Sony amp. I eventually got fed up with that.

For the past few weeks I have been using my One-for-All Xsight Colour remote (I had loaded the Ortek/Hama definitions into it some months ago as a test). It is my second most-capable remote (my worn-out MX850 comes first), but I really dislike the buttons on the Xsight Colour -- most of the buttons are small and nearly flush with the casing, making them difficult to press.

There is at least one MP user who really likes the Xsight Colour (or the similar Xsight Touch), so I suppose that it could be called a "Marmite" remote (I think the equivalent in your part of the world would be a "Vegemite" remote) -- you either love it or loath it. I tend towards the latter. So I feel a change of remote approaching...

-- from CyberSimian in the UK