View Single Post
Old 2008-04-07, 23:49   #78 (permalink)
nobbly
Portal Member
 
Join Date: Sep 2007
Posts: 13
Thanks: 1
Thanked 0 Times in 0 Posts

Country:


Default

Quote:
Originally Posted by nobbly View Post
Quote:
Originally Posted by and-81 View Post
Sorry mate, I really can't offer any advise in regards to Girder. I don't use girder. The only thing I can suggest is to use the mce replacement driver plugin for girder but with the modified registry settings with the default driver. If you haven't already tried that.
Perhaps I didn't make it clear in my above post the reason why I was posting. To put it bluntly, your statement that 'the Replacement Driver is obsolete' appears to be incorrect. In your original 'unedited' initial posting, which detailed the first method (which was then edited out by you and replaced with the second method), you made it very clear that the method worked with Girder and HIP when using Bruno Fleurette's MceIr.dll. In that original posting you provided a zip file entitled 'Why the MCE Replacement Driver is now obsolete.zip'. Within this zip file was a text file in which you stated:

Quote:
Originally Posted by Why the MCE Replacement Driver is now obsolete.txt
Once you've disabled the automatic handling you will need some other software
to pick up the task. Most third party remote handling programs (like HIP,
Girder and EventGhost) should have no problem with this because they access
the device directly instead of going through the HID driver.

This process should work on all version of Windows that support the
Microsoft eHome Infrared Transceiver. I've tested on Windows XP Pro and
Windows Vista Home Premium and it worked on both.

However, please note that as I write this HIP, Girder and EventGhost can't
use the default Windows eHome driver in Vista. On Windows XP these programs
are fine because they use Bruno Fleurette's MceIr.dll, but these programs
need the Replacement driver for Vista and I haven't been able to get the
Replacement driver to work on 64-bit Vista yet, only 32-bit Vista.
However neither the first method or the second method (of just removing the registry entries and rebooting) work with Girder when using Bruno Fleurette's MceIr.dll. And I suspect that these methods also do not work with HIP (unless you know better). I would have thought that if it had been so easy as to just remove the three registry settings, that Bruno Fleurette would have sussed this out rather than go to all the trouble of creating the replacement driver.

I originally posted above to point out that your methods do not work in Girder, as you did state that they would.

The only statement that appears to be correct and currently verifiable, is that for your own application (which looks very promising) you no longer need to use the replacement driver. What I am really rather disappointed at is that you appear to then jump from this and state that all the other remote control applications no longer need the replacement driver, when actually it appears that they still do need the replacement driver.

In fact, the replacement driver is far from obsolete for those that do not use your software. For many who use Girder and HIP etc, the replacement driver is essential as there appears to be no other way to bypass the eHome driver.

The only way of getting your second method to work in these applications, is to use their built in HID support. But this is wholly different to using the replacement driver as you can no longer use different remotes and have to use the original MCE handset. The benefit of the replacement driver is that you can use many other remotes including the original MCE handset.

To conclude, I think it is only fair to those that have read your statements and then spent some time trying to get your methods to work and then only to find that they don't (such as myself) that you:

1. Explain fully why you have made the statement that your methods work with the applications, when it appears that at least in Girder they do not (and I suspect they do not in any other application you quote);
2. That you re-edit your first posting to make it clear that the replacement driver is only obsolete when it comes to using your own software, and that the replacement driver is still probably needed for all other remote control software such as Girder/HIP etc.

Of course, if I am completely wrong in this, and your methods do actually work as you state in Girder/HIP etc, then please let me know (or anyone else who has tried to get these methods to work, please post!).

PROBLEM SOLVED!

The reason why the method of using the ehome driver and registry modifications with Bruno Fleurette's original MceIr.dll and Girder did not work on my system was that apparently the original MceIr.dll has a bug which means it tries to communicate with a couple of USB DVB-T boxes I have installed (Nebula DigiTV units), and I quote from http://www.digitv-forum.co.uk/viewtopic.php?t=2153:

"There is a bug in an earlier version of the MCEir.dll (ie nothing whatsoever to do with DigiTV), that causes it to try to talk to the DigiTV USB device, rather than talking to the MCE IR receiver. This causes bad things to happen. I (HR) fixed the MCEir.dll code a while ago (thankfully the source was available, and thanks to Anarchi who reported the problem) and provided the updated version to the author of HIP."

I can confirm that it is also a problem when using Girder as the version I have (3.3.10) also uses the same MceIr.dll as HIP (http://www.byremote.com.au/HIP/Default.htm). The problem disappears when the USB DVB-T units are disconnected and then the 'ehome driver method' works exactly as if the replacement driver were being used.

The updated MceIr.dll by HyperReality (HR) is available from here:

http://www.byremote.com.au/downloads...SS=HIP%20EXTRA

This works in Girder and allows the 'ehome driver method' to work when the USB DVB-T units are connected.

This bug could be unique to when these specific USB DVB-T units are attached, although if anyone else is having the same problem of not being able to get the 'ehome driver method' to work then it could possibly be due to the bug in the original MceIr.dll causing problems with similar USB devices attached. If so, then use the updated MceIr.dll from HyperReality in the link above.

P.S.: Apologies to and-81 for my rather harsh second posting!

Last edited by nobbly; 2008-04-08 at 05:27.
nobbly is offline   Reply With Quote