Microsoft MCE Remote - Vista and newer

[bzyrrt]

(Edited, old post below) That was probably rubbish. Besides the other thread where people with onboard receivers have problems ( viewtopic.php?f=9&t=3527&p=24693#p24693), I did not find out anything useful.

The service *seems* to connect to the correct interface, as it returns some information about the receivers that is correct and unlikely to have happened "on accident".

Does anyone know where to get some more information or a reference? The only thing I found is this (and related pages), but that's hardly comprehensive. It also seems like the hard-coded enums and data structures in the file were once extracted from the official development sources. Would that be the WDK?

Pretty frustrating, as everything seems to sort-of work for me, besides the fact that no IR data ever arrives once the MCE interface has been setup. I also tried out RichardH's version, but the results are mostly the same:

00000001 0.00000000 [6376] VistaGetDeviceCapabilities() ENTER
00000002 0.00007078 [6376] IoControl ENTER
00000003 0.00010086 [6376] IoControl: hReadPipe is valid
00000004 0.00013236 [6376] IoControl: Event created successfully
00000005 0.00016244 [6376] InSize = 0, OutSize = 40
00000006 0.00023499 [6376] IoControl: bytesReturned=40
00000007 0.00026154 [6376] IoControl EXIT
00000008 0.00029126 [6376] Device Capabilities:
00000009 0.00031675 [6376] NumTxPorts: 2
00000010 0.00034258 [6376] NumRxPorts: 2
00000011 0.00036912 [6376] LearnPortMask: 0x1
00000012 0.00039496 [6376] ReceivePort: 1
00000013 0.00042044 [6376] LearnPort: 0
00000014 0.00044627 [6376] DetailsFlags: 0x4
00000015 0.00047353 [6376] Connected to \\?\root#system#0002#{7951772d-cd50-49b7-b103-2baac494fc57}\port1
00000016 0.00050078 [6376] Using port 1
00000017 0.00129848 [6376] Creating named pipe
00000018 0.00135687 [6376] Opened MCE IR device interface
00000019 0.00140748 [6376] Before StartReceive
00000020 0.00143650 [6376] ***************** OutputConnectionsThreadProc() before wait
00000021 0.00147791 [6376] VistaStartReceive() ENTER
00000022 0.00151684 [6376] Waiting for connection...
00000023 0.00155435 [6376] IoControl ENTER
00000024 0.00158373 [6376] IoControl: hReadPipe is valid
00000025 0.00161735 [6376] IoControl: Event created successfully
00000026 0.00164672 [6376] InSize = 16, OutSize = 0
00000027 0.00172529 [6376] IoControl: bytesReturned=0
00000028 0.00175183 [6376] IoControl EXIT
00000029 0.00177767 [6376] After StartReceive
00000030 0.00180704 [6376] IR pump thread using normal receive port
00000031 0.00189587 [6376] Starting IR Pump Thread
00000032 0.00193834 [6376] IR Pump Thread, before IoControl
00000033 0.00196347 [6376] IoControl ENTER
00000034 0.00198895 [6376] IoControl: hReadPipe is valid
00000035 0.00201868 [6376] IoControl: Event created successfully
00000036 0.00204664 [6376] InSize = 0, OutSize = 132
00000037 0.50090510 [6376] ***************** OutputConnectionsThreadProc() after wait, Stop = 0
00000038 0.50098759 [6376] ***************** OutputConnectionsThreadProc() starting LOOP?
00000039 0.50103855 [6376] Waiting for data or close

I did some more testing. It seems most likely to me that the wrong CIR interface is opened, as pointed to by this thread: viewtopic.php?f=9&t=3527&p=24693#p24693

Probably the current service tries to open a USB receiver, though my board has a hardware CIR header. No idea why opening the interface does not fail in my case.

I don't know much about the GUID stuff that's used to identify the correct device class - I will try to do some testing with values I get from the device manager.

In the meantime, can somebody where this service is working confirm that 7951772d-cd50-49b7-b103-2baac494fc57 is indeed the class GUID of their IR receiver?

How to check: https://technet.microsoft.com/de-de/lib ... 10%29.aspx

The device should be found under HID Devices. If I'm correct, I can hopefully fix this for some more people that have onboard CIR headers, too!

[Sem;colon]

I have two devices in the Device Manager - one is HID and one is USB:

The class GUID of none of them matches the GUID from your post.
I hope that helps!

[RichardH]

@bzyrrt
Good to see you got my version of the service running. Shame you're not getting any benefit from it, though. Your DebugView log shows a normal startup, and the service is waiting for input. What it also shows is that it found a device that is (apparently) compatible with this plugin on port 1 of the interface, which is the first place it looks. This device has the 'right' device capabilities, so that's where the search ends.

If you really do have more than one compatible IR device connected to your system, then they will all show up in device manager as 'Microsoft eHome Infrared Transceiver' (or a local translation), like the one on the right in semi;colon's post. They will also have the same device class GUID, as shown in that picture. If you don't have more than one, your problem has a different cause. How many of them do you actually see?

(Incidentally, the GUID you mentioned, which also appears in the DebugView log, is the interface class GUID for the device type. This, confusingly, is not the same as the device class GUID mentioned above and in the TechNet article.)

Richard H

[bzyrrt]

There you go, I got one MS eHome Transceiver and another HID device from Nuvoton (manufacturer of the chip on my Intel MoBo):

Could this already be part of the problem? I managed to install the WDK on VS 2013 and verified that what the driver is actually doing is setting the IR device into "priority receive" mode (which seems to work). Then, I also found out that the driver hangs after the first "Priority Receive" IOCTL call, which I find weird.

According to MSDN, the call should return if

• the timout of 100ms (hardcoded in driver) passes
• the data buffer is filled
• immediately, if the device is not in priority receive mode

So, why does neither of these things happen, according to the log? No error, no timeout, no data. Is is maybe after all related to the wrong device being opened?

[RichardH]

@bzyrrt
I know nothing about the Nuvoton device, so I can't say how or if your problem relates to the conflict that my BlackGold IR receiver caused.
Firstly, it is not yet clear that either of the two devices that shows up in Device Manager will behave just like a genuine MCE Transceiver, and is therefore compatible with this plugin.
Is it correct that the only physical IR receiver you have is the built-in Nuvoton? If you disable the Nuvoton device (in the BIOS), do both devices disappear from Device Manager?
If you disable this plugin and its service and restore the registry, can you control WMC fully with the remote control? For instance, if WMC is not running, do the 'Live TV', 'Guide' and 'Recorded TV' buttons start it? If not then the Nuvoton is probably not compatible with this plugin after all.
Otherwise, it would be nice to know which of your two devices the EventGhost plugin is attaching to, and whether it should be attaching to the other one instead.
If you look in the Device Manager details under 'Siblings', do the two devices refer to each other?
You can look further in Device Manager under 'Device Instance Path' for the two devices, which should end with different port numbers. You can then see which one matches the 'Connected to ...' line in the DebugView output (for my version of the service).
Since you are able to build the service yourself, you could add your own Trace calls (among other things), for instance to see if the driver really is hanging. It would also be easy to alter the code (as an experiment) to make the service continue searching after the first device found. I could point you in the right direction if you like.

RichardH

[bzyrrt]

@RichardH
Thanks for taking the time!

Firstly, it is not yet clear that either of the two devices that shows up in Device Manager will behave just like a genuine MCE Transceiver, and is therefore compatible with this plugin.
Is it correct that the only physical IR receiver you have is the built-in Nuvoton? If you disable the Nuvoton device (in the BIOS), do both devices disappear from Device Manager?

They disappear both.

If you disable this plugin and its service and restore the registry, can you control WMC fully with the remote control? For instance, if WMC is not running, do the 'Live TV', 'Guide' and 'Recorded TV' buttons start it? If not then the Nuvoton is probably not compatible with this plugin after all.

I've got Win 8.1, so no included WMC. But I can control XBMC just fine, i.e. the arrow keys, Play/Pause/Forward/Rewind, OK/Exit and so on all work.

Otherwise, it would be nice to know which of your two devices the EventGhost plugin is attaching to, and whether it should be attaching to the other one instead.
If you look in the Device Manager details under 'Siblings', do the two devices refer to each other?
You can look further in Device Manager under 'Device Instance Path' for the two devices, which should end with different port numbers. You can then see which one matches the 'Connected to ...' line in the DebugView output (for my version of the service).

I'm on a localized German Windows, though from some googling and looking at other nodes, "siblings" is translated as "Gleichgeordnete Elemente".
The MS eHome does not list any siblings. It has Instance path CIRCLASS\IRDEVICEV2\1&1A590E2C&0&PORT1
The Nuvoton device has instance path ACPI\NTN0530\4&3AC6C14A&0, and a lot of siblings:

Code: Select all

ACPI\PNP0200\4&3ac6c14a&0
ACPI\INT0800\4&3ac6c14a&0
ACPI\PNP0103\0
ACPI\PNP0000\4&3ac6c14a&0
ACPI\PNP0C02\2
ACPI\PNP0B00\4&3ac6c14a&0
ACPI\PNP0100\4&3ac6c14a&0
ACPI\INT3F0D\4&3ac6c14a&0
ACPI\PNP0C02\111
ACPI\PNP0C02\10
ACPI\PNP0C04\4&3ac6c14a&0

From the above logs, it looks like it's connecting to the MS eHome device. And from the different prefix of the instance path, I gather that the Nuvoton entry belongs to a totally different device class? So, maybe not compatible after all?

Since you are able to build the service yourself, you could add your own Trace calls (among other things), for instance to see if the driver really is hanging. It would also be easy to alter the code (as an experiment) to make the service continue searching after the first device found. I could point you in the right direction if you like.

Sure, this would be great! Also, if you know of a primer on how to make sense of these different types of GUIDs and hardware paths, that would be really helpful.

[peglegtv]

- place your IR sensor somewhere were it can't be influenced by direct sunlight or ligt from a plasma TV.
- If you run EG as admin, the version from the first post will restart the service as soon as it crashes.

I had to restart EG on Sunday night because it lost connection again, how ever I did notice that my kids Wii was on and the Ir bar was about 8 inches away from the receiver so I move the receiver and its been good so far


thanks for the help

[RichardH]

@bzyrrt
So there is only one device instance that might work with this plugin - the one with Microsoft in the name. Both versions of the service attach to that one, so that's not the problem. It's a fairly safe bet that the device instance with Nuvoton in the name can be disregarded (probably has to do with CIR functionality but not with remote control).
That leaves what you noticed about the driver responding sensibly to some IOCTLs, but appearing to block on IOCTL_IR_PRIORITY_RECEIVE.
(You had already reached these conclusions yourself, I think.)
If the above is right, then you don't have to worry about GUIDs. The only one that might have been relevant is for the device interface class.
To work with this plugin, a device has at least to support the right device interface class. However, there are evidently devices out there that claim to do so, but do not properly emulate the genuine MCE Transceiver - and yours might be one of these. The fact that it works with XBMC (at any rate while it has the focus) is not enough in itself. That's why I asked about WMC.
While relevant, I think the IOCTL documentation you found applies to what happens a bit deeper down in the architecture than where the service operates. The service passes IOCTLS to the driver through the Windows library function DeviceIoControl(), having first opened the device in overlapped I/O mode. This means that DeviceIoControl() always returns immediately, but the result may come some time later. You can see this at line 1604 in my version, where a WaitForSingleObject() immediately follows DeviceIoControl(). If you suspect that DeviceIoControl() is not returning, you could check by adding a Trace(...), or a DebugIoControl(...), call immediately before WaitForSingleObject(). There are already a couple of these before DeviceIoControl(), so your new message should always appear in the Debug view log immediately after these.

RichardH

[bzyrrt]

Just a short note: I've been writing a small diagnostic tool (and taking this as an opportunity to learn about the Windows device driver model), and I have good news:

I can successfully retrieve data from the receiver, albeit with a regular IOCTL_IR_RECEIVE and *not* an IOCTL_IR_PRIORITY_RECEIVE as the MceVista service does. The IOCTL naming is a bit off since the
MceVista service does not include the irclass_ioctl.h but just uses the correct constants, but with different names (i.e. PRIORITY_RECEIVE becomes StartReceive).

I'm optimistic that I can get this to work somehow.

[RichardH]

bzyrrt - well done!

[unicus]

Hello, I have the exact same issue as bzyrrt. I have an Intel i5 NUC with the built in Nuvoton CIR. My HID devices and class GUIDS are the exact same as yours. My remote works flawlessly within XBMC like yours but as soon as I install the service with the MCE remote plugin it stops working. If I uninstall the service it works fine again. I love the functionality eventghost brings, and I am curious if you got it working?

[Stewlacher54]

I'm having some minor trouble with the Microsoft eHome IR receiver and the MCE Remote plugin. Everything works ok, but there is a constant stream of MceRemote.Unknown events for a number of different values. It's just constant spam of 20 or so events per second and it seems to lag the rest of eventghost a little bit. It's not the worst problem in the world but it's getting rather annoying seeing the red light on the receiver constantly flashing and the little bit of lag I get from using the rest of the events. My last HP receiver worked fine except it would just stop working at times and I couldn't figure out how to get it working again, it would just start working on its own after a while. So I replaced it with the Microsoft one and other than this issue it's been great. I'm attaching a screenshot of what it looks like for reference. I made sure I didn't have anything else around that could be sending the signals, I completely covered the receiver and it still shows the steady stream of events in EventGhost. I also tried a different USB port but no difference. Hope someone has run into this before and has a fix, thanks!

[wacind]

Hi.

Ive been banging my head over this all morning and would love some help:

I recently bought this HP MCE controller (http://www.amazon.com/Control-Receiver- ... B00AYE6JDO)

i plugged it in and loaded the plugin in Eventghost.
everything seems to work fine except the learning functionality. the plugin logs what button was received through the IR receiver, however when i try the learning functionality, it simply does nothing. It stays on the "learn ir code" dialog box and does not close automatically or provide the code for the button that im trying to teach it.

Ive tried adjusting the learn counter but nothing happens.
any help on what im doing wrong would be appreciated. Do i need different drivers?

Thanks

Edit: Ok i managed to the the learn code functionality working on my other computer, i just have to press the button on my remote a whole bunch of times.

Now my issue is that any button presses seem to produce different IR codes each time and none of them actually work when i transmit the code. Im not sure if i have to do anything with the repeat counter.. any ideas?

Edit 2: I figured out that most of my issues could have been due to the range of the HP MCE receiver/emitter. They only work when i hold the remote right infront of the receiver and the emitter only seems to send signals to devices that are less than an inch away. Looks like ill have to find a new receiver/emitter

[TRIROG1]

i added the plugin and installed the service.
And eventghost detects events normally.

Quick question:
Is it normal for EG to hijack all the commands i.e. after i install the service and restart the PC, i can still receive events in EG but my Mediaportal no longer responds to the keypresses.

Is there a simple way to just tap in the MCE remote and detect events but not hijack them?

Thanks!

Also how can i emulate keypress for the coloured teletext buttons ?

[bxr]

When transmitting IR, event ghost freezes for seconds(!). It doesn't happen all the time.
I think it happens with USB-UIRT as well but I'm not sure (I have them both connected but in different rooms).
I tried to search for such error on the forum and didn't find a solution.
Any idea?