EventGhost

[edit]9/7/2009 New version. Bug fix (see here for details).[/edit]
[edit]9/2/2009 New version, with working learn capability and lot's of cleanup.[/edit]
[edit]8/21/2009 Fixed Vista32 bug, added ability to transmit pronto codes (see this post).[/edit]
[edit]8/19/2009 dump bug fix in pronto transmission code fixed.[/edit]
[edit]8/18/2009 New version available. The attached version

* Includes preliminary blaster support
* Can be installed from the plugin configuration, rather than separate msi (requires EventGhost 0.3.7.r1187, released today)
* Should work for both 32 and 64 bit Vista or Win7

The installers are still included in the zip file for Melloware's benefit.
See this post for details on the blaster capability.
[/edit]
The current MceRemote plugin relies on a dll that won't work on Vista/Win7 unless it is called with elevated privileges. This is a known problem, and it arises from the fact that Windows installs the IR receiver's driver with restricted access controls. For more detail, you can reference this thread or this one.

In order to solve this problem, I've followed the path MediaPortal took, which is to create a windows service that attaches to the driver. The service is installed and runs at elevated rights, so it can connect to the IR driver. Any received messages are then pushed out on a NamedPipe, which is created at "normal" privilege. A new EG plugin can then connect to this pipe to handle IR events.

One advantage of this is that I pass ANY ir signal to EG for processing, so using this service/plugin allows you to handle any remote, not just the MCE remote.

If you'd like to give it a try, unzip the attached file in you eg/plugins folder, install the included service from the msi (will require reboot), and enable the new plugin from with EG.

If you have any problems/suggestions, please post here.

Notes:
0) This should be considered beta code. It works well in my testing, but that only includes testing on one Win7 32 bit install. Source code for the service is included in the zip file.*
1) The service does not support "blasting" from the MCE remote.
2) Right now it forwards the power button as any other button press, so there is no sleep/suspend capability.

*I created the msi installer using WiX, which requires VS2008 standard/pro. Because of this, I did not included the installer (or the helper dll that removes/restores the CodeSetNum registry keys) with the source code.

Brett

BTW, I'm still cleaning up the installer (it is super basic right now). But since there were posts about the old Mce remote plugin this morning, that seemed like a good reason to get this out there sooner rather than later.

[edit 8/4/2009]
I wanted to provide some additional detail about why you need to run an additional service in order to get an MCE remote working with EG on Vista or Win7. Many of you already know why, but it seemed reasonable to make sure everyone was up to speed.

The main problem is that the original Mce Remote .dll couldn't attach to the Mce Receiver device on Vista or Win7 unless it was run with administrator rights. Running a python scriptable program like EG at that level is probably unwise. In order to overcome the problem, there really needs to be two processes running. One, that attaches to the Mce IR device, that has elevated privileges. The other, a new EG plugin (MceRemote_Vista) that can run with normal rights. To pass information between these two process, some form of IPC (inter-process communication) is required. I chose to use a named pipe.

A named pipe is like a socket, but with a name instead of an IP address. The name just makes it a little easier to attach both ends. It's a way of communicating between processes or machines (an ip address is still needed if you connect between different machines). The main reasons for going to a service are:
1) The service can be run elevated, so it can attach to the MCE IR driver. The namedpipe is created, but set at lower rights, so EG can get the data without being elevated.
2) As a service, it will run without any user logged in. I thought this would be useful, assuming I could get power/sleep part working (which isn't at the moment). I also thought that at some point, moving directory watching to a service might make sense, but if I do that it will be down the road.

The original Mce code is still mostly there. The main problem was that it ran as a dll, so the dll is run with the same privileges as the process that loads it. That's why EG had to be run as administrator in order for the original plugin to work. As a separate service process, it has it's own rights assigned, in this case admin rights. The old code translated the ir to messages within the dll and forwarded the messages to a window. I took out that translation and just passed the ir data along the pipe. This way EG does the decoding itself, and it isn't tied to any hidden window.

I intentionally kept the service very basic (as basic as possible while still handling threading issues), so I don't think there is risk it causing harm. I also provided the code so people could see exactly what it was doing (I'm nervous installing services without knowing what they do, just like everyone else).

As has been mentioned in other threads, MediaPortal has gone down this route as well. I've taken advantage of a lot of work by others to make something that will run from within EG.
[/edit]

Brett

Nice to see someone actually tries to bring this forward. I will try it more extensively as soon as I have some time.

I assume the installer will just install a service.exe. I like to limit myself to only use free tools and VS2008-Express doesn't seem to be enough to build the installer, right?

One alternative could be to install the service through the plugin with some Python code (similar as it currently disables the IR service registry keys). I have found this so far: http://essiene.blogspot.com/2005/04/pyt ... vices.html (the second part about installing the service). But it might be needed to start another Python process with elevated rights to do so (so the user doesn't have to restart EG with admin-privileges just to install the service).

Another one would be to use InnoSetup.

Btw: Since your plugin code uses WaitForMultipleObjects itself, using eg.ThreadWorker might be the wrong choice. I assume a normal standard lib threading.Thread would be more appropriate.

The installer installs the service and calls a helper function to remove (and restore on uninstall) the registry keys. Nothing else. The code for changing the registry keys is basically what I put in the MceRemote mode (in python) posted in this thread, except I only change the ...DA and ...DB keys now (I was afraid I might stop keyboards from working).

Also, Windows Installer XML (WiX) toolset is free and includes a plugin (votive) to run it from within VS2008. The only problem is that VS Express won't let you install plugins. WiX can be run from the command line, and I have no problem providing the current "code" for the installer. I just have it set up within VS to create the installer when the code is built, so the solution won't load without WiX.

BTW, I created an installer using a VS2008 deployment project. The problem was that I needed the installer to schedule a reboot, and the standard project won't let you do that (you need to run a separate tool [orca] to add that in). So I went with WiX to simplify builds.


I'm not sure where you're heading here. Mind explaining what are the above would fix?


I was using eg.ThreadWorker since there were already working examples. It looked like the class was a pretty thin layer between code and threading.Thread, which just simplifies starting and stopping the code from a plugin. Is there extra overhead the is harmful in this case?

Thanks for the feedback!
Brett

The registry keys doesn't seem to work on my machine. The MediaCenter was starting on some buttons after installing/reboot. I had to run the old plugin one time to get the default service disabled.

There are actually two ideas in it. The first one was to use free tools, but as you explained this might not be the problem. The other one was to automate the process of installing the service by the plugin, so the user just would only need to install a single item (the plugin). Since the next versions of EG will support easier installation of additional plugins by just double-clicking them, it might be desirable that there is no additional installer needed to get everything working. And as you might guess, I have an addiction to do as many tasks in Python as possible.


eg.ThreadWorker is a message pumping thread with the ability of queued execution. I don't think any of these features is needed by your code, as you are using a closed loop yourself. So I assume you could just put Setup()/Run()/Finsih() into a single function and threading.Thread will work without the risk of possible side effects.

Quick question on this. Did the installer finish with a messagebox asking when you wanted to reboot or did it just close? If it just closes, that means there was a problem with running the registry step (probably permissions of some sort). If it asked about a reboot, then it should have worked properly. Knowing the answer helps me troubleshoot. Adding feedback is something I need to fix in the installer....

I like the idea of allowing the plugin to install the service. There is a registry key that can be used to tell if the service is installed. Is it possible to attach a button to the plugin's configure that would spawn an install process? The service's .exe can be installed simply by passing "install" as a command line parameter (but that has the problem of elevating privileges), or maybe the button could just start the installer? The button could be enabled or not based on the registry value. I'd like your thoughts on that....


I'll take a look at just using threading.Thread. I've got a test program that isn't attached to EG that already uses threading.Thread, so it shouldn't be difficult to change.

Brett

No, it has asked for a reboot.

I assume it would be no problem to add such button and spawn a process, but I would like to actually make it more seamless. Once the plugin gets installed by the user, some Python function can be called that would check if the service is installed and if not would initiate the installing. The same function can then be called everytime the plugin gets started to check if the service is still available and reinstalls it if needed. If the user uninstalls the plugin or EG completely, another function can be called to initiate the uninstalling of the service.

Some other feature that I might introduce in the future is an automatic finding of appropriate plugins by scanning vendor/device hardware identifiers. So if the EG installer detects a compatible eHome transceiver, it can prompt the user with the information, that he needs to download plugin XXX to get this device working. To make this work, we need to collect compatible IDs. Mine for example shows as USB\VID_0609&PID_031D&REV_0000

FYI, I edited the 2nd post to add some detail about what the service is doing.

Hmm, that's not what I was expecting to hear. In order to fix this, I would like to know what the registry values looked like before and after reboot. If you get the chance to test again, would you mind checking the ...DA and ...DB registry keys to see if the CodeSetNum[0/1/2/3] values are present a) before the installer runs, b) after the installer runs, but before a reboot, and c) after the installation and reboot? The first thing that comes to mind is some people have talked about the Mce driver reinstalling the software each reboot. My remote doesn't work this way, maybe yours does?

Sounds good.

Brett

Today I get the following message on Windows 7 RC 32bit every time:

The last message means something like "all pipe instances are utilized". But the plugin still works.

It is really nice, the plugin uses the eg.IrDecoder. But it looks like I have to fine-tune the decoder in the future, so it works as reliable as the original decoder.

Do you have any plans to work on the blasting stuff also? It is to long ago that I have looked into the old code of the old replacement driver of Bruno Fleurette, but it looked like the blasting would use the same format as the receiving (these continues 8-bit streams). If we would have an interface to this blasting feature, it would be time to create some kind of generic eg.IrEncoder.

Ok, here's a quick update.

This version doesn't use the eg.ThreadWorker class, instead it uses threading.Thread directly.

I was also looking at the sleep capability. I knew that if the machine was awake, the remote's power button would generate an IR code that eg could use. Because of that, I thought that my service would need to handle some sort of event to wake from sleep. But it turns out that only devices are kept awake and able to wake the computer, and the Mce IR device is already set up to do that. So wake from sleep just works. And, since EG has actions for putting the machine to sleep already, they can be triggered by the Power event if desired. One more thing off the list, and no coding required! I love it when that happens.

Also, I changed the install code to remove ...DA, ...DB and ...DC registry codes for CodeSetNum. I'm hoping that fixes the problem BitMonster had.

The new version is attached.


The following message should appear later in the log: "MCE_Vista: Connected to MceIr pipe, started handling IR events", which is output if the client can't connect initially (which prints your message), but is able to connect later. What usually happens is that EG was started/stopped, with the service still running. The service only accepts one connection, which is kept open until a write fails. If EG was started/stopped with the connection open, starting EG again will hit this condition. But once a write fails, which should happen on any new IR signal hitting the receiver, the service tries to connect again and everything will start working. The only alternative would be to have the service periodically try to some sort of "heartbeat" message to tell if the connection goes down, which seemed like overkill.


??? It is the original decoder. I'm not sure what you mean. I do know that my USB-UIRT seems a bit more reliable, but I just assumed that was differences in the accuracy of the device measuring the IR pulses. Do you mean eg.IrDecoder needs to be tweaked for this device?


I don't think this would be hard to add, but the particular Mce Receiver I have doesn't have the blaster ports. Yes, the original code had hooks for this, and the format for output should be similar to the input to eg.IrDecoder. Does most of the EG code already exist for the USB-UIRT blast functionality?

Brett

I would have guessed, that a closed pipe would initiate some event to the producer. Anyhow, since blasting would need a pipe in the other direction, it might be used also to inform the service of the disconnection.


Currently eg.IrDecoder seems to have some problems to get the reception right under some conditions. I might change this in the future, so it has a greater addiction for RC6 codes.


No, the USB-UIRT uses its own handling of the blasting stuff. Tira also, so there was no need for a generic IR encoder till now. But once something like an eg.IrEncoder is written, it might also be useful for the USB-UIRT and other devices, as it would then also be easy to convert "known IR events" of the eg.IrDecoder to Pronto format and the USB-UIRT can handle this also.

I just managed to install and uninstall your service with a programmatic elevation prompt with pure Python from inside EG. Starting and stopping the service also works. I still have to clean up the code, but now it should be no big problem to get the service installation integrated into the plugin.

Since your MCE receiver hasn't any blasters ports, how about buying a second original one from the projects donations? If you want to take the job, send me through PM a link to the shop you want to use, what it will cost (incl. delivery costs) and some PayPal account you want the money to be sent to.

Bitmonster-

Sounds good on the installer front. As for the blaster, I was looking at the code and I only see the blaster functionality implemented for XP, not Vista. I'm still looking around (I posted a question over on the IRSS section at mediaportal), so cross your fingers.

Brett

Brett,

Trying to get this working. I installed the Service and rebooted my machine a Windows Vista Service Pack 2 machine. I have the standard Vista MCE REmtoe with MCE eHome dongle.

Using EventGhost 0.3.7.r1170 which is the latest download available on the site. It says it is connecting to the pipe fine but when I press buttons on my remote I see my IR Dongle blink but not receiving any events in EG.

Is there a step I am missing? I had previously deleted my registry entries HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\HidIr\Remotes\745a17a0-74d3-11d0-b6fe-00a0c90f57da for the keys from "CodeSetNum0" to "CodeSetNum3". Do those need to be there? Also I have the Human Interface Device Service stopped, should that be started?

Any thoughts would be appreciated.

The service shouldn't depend on any other services, since it is communicating directly with the device (unless another service is required for the device to run, which I don't think is the case).

So the EG plugin says it is connected? I would try opening task manager, going to the services tab, and restarting AlternateMcrIrService. Then disable/enable the plugin. Can you also see if there are any event messages in the system logs? Open the control panel and open System & Security->Administration Tools->View Event Logs. Within that window, check Windows Logs->Application and Windows Logs->System for any messages with a source of AlternateMceIrService. Maybe there was an error connecting to the device.

Are you on 32 or 64 bit?

Brett