[OBSOLETE] MCE Replacement Driver (1 Viewer)

Status
Not open for further replies.

and-81

Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    Maverick494:

    It looks like the driver is sending back the right information, but in a format I wasn't expecting ...

    usually the device sends back data like this:

    84, xx, xx, xx, xx, 81, xx, 80

    where the 4 in 84 is telling me to expect 4 items of data, and the 81 tells me to expect 1 more, and the 80 is a terminator.

    But yours just seems to be sending the data without any framing ... I'll pass this through my decoder a little later today and see if it decodes to something intelligible ...

    If it does I'll post a test app specifically for your setup...

    As long as the data coming from the driver is not scrambled (and that's why it's missing the framing bytes) then I should be able to decode it...

    I'll get back to you soon.

    Cheers,
     

    and-81

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    ok,

    Having looked at the data and tried to convert it into a time code, I believe that there are 2 bytes being clipped off the start of the data... because the time code is not intelligible.

    So where the log says:

    2008-03-17 08:30:07.216375 - Received data:
    7F, 7F, 5C,

    I think it should say:

    2008-03-17 08:30:07.216375 - Received data:
    84, ??, 7F, 7F, 5C,

    But because of a difference between 32 and 64 bit systems it isn't ... I'll try re-jigging the data structures to see if I can find those two missing bytes ...

    I'll post a new test app for you within the next 24 hours...

    Cheers,
     

    and-81

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    I can't seem to find anything obvious that might make a difference, but I have changed a few bits & pieces...

    Try the attached file and send back any logs it generates...

    Thanks,
     

    Maverick494

    Portal Member
    March 7, 2008
    13
    0
    Home Country
    United States of America United States of America
    When it goes to learn IR it times out every time. It doesn't appear to generate any log, but I am not sure where it would put the log.

    unless the log is the PDB file
     

    and-81

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    The log file should be in Documents and Settings\All Users\Application Data\IR Server Suite\Logs

    if not then I'll post a new version that will create it's log in the same folder it's executed from...

    Thanks,
     

    and-81

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    Hmm, it's quite strange...

    The device is not responding to any of the codes that are being sent to it ...

    If you look at the start of the log file:

    Code:
    WriteSync(3): 00, FF, AA, 
    WriteSync(2): FF, 0B, 
    WriteSync(2): 9F, 05, 
    WriteSync(2): 9F, 0D, 
    WriteSync(4): 9F, 0C, 07, D0, 
    WriteSync(3): 9F, 14, 01,

    Keeping in mind that this is all just bits and pieces I've learned by monitoring Media Center with a usb packet sniffer...

    00, FF, AA is a start up code. I think it just wakes up the device.

    FF, 0B is a request for a device version number (I think it's a firmware version of something like that). This always gets a response on other systems.

    9F, 05 and 9F, 0D are things that Media Center does that I haven't figured out yet, but they also get a response on other systems.

    9F, 0C, 07, D0 sets the timeout period.

    9F, 14, 01 tells the device to use the "01" receiver (which is for normal long range IR receiving).

    You'll then see that when the learn starts it sends: 9F, 14, 02 (which is to start the learning).

    But when each command finishes it has this on the end: 9F, 14, 01

    Which tells me that it is on receive port 1, and not 2 as instructed ... it's like nothing I send is getting through.

    And what's worse ... the received data still doesn't have the framing bytes I need ...

    I'm at a bit of a loss as to what else I can try ... I don't know if this is a 64-bit issue or something wrong with the driver you've installed...

    It's very frustrating ...

    If I think of something else to try I'll let you know ... but I have to admit that I'm a bit stuck without access to a 64-bit development rig. :(

    With a 64-bit development rig I'm pretty confident I could get the 64-bit replacement driver build to work too.

    Anyway, I'll keep it in the back of my mind and if I think of anything I'll get back to you... I feel like we are so close, it's really driving me mad...

    Cheers,
     

    jbsmathers

    New Member
    March 20, 2008
    2
    0
    Home Country
    United States of America United States of America
    Do Vista (32bit) users still need the mce replacement driver?

    I've been pouring over the MCEIR threads for a few days, and have tried a number of things, but I have lacked success and remain confused about how I should proceed.

    I simply want to see my mce remote button pushes registering or logging in one of the applications lik hip, girder or eventghost.

    I am running vista (32 bit). My mce remote works fine with MCE using its default driver.

    I see for a while people used a replacement driver for the MCE remote receiver, but more recently that was pronounced absolete, as some registry changes were discovered which allow the MCE remote to function as needed using its default driver.

    I have two questions. 1) If I am running vista, should I still follow the instructions for the vista replacement driver, or make the same XP (or different) registry modifications for vista?

    2) (forgive my ignorance here) to get one of the above mentioned apps to log my remote button pushes, (assuming i've made either the needed driver or registry changes) do I also need a mceir.dll file? IF so, do I need a file specific to the given app mentioned above, if so is it expected that one .dll file will work with all these apps, or does each app require a mceir.dll written just for it?

    Assuimg I do those two things correct, is there any thing else i must do to expect to see my remote button pushes being logged.

    :confused:

    A million thanks to anyone who can help advance my knowledge here!
     

    and-81

    Retired Team Member
  • Premium Supporter
  • March 7, 2005
    2,257
    183
    Melbourne
    Home Country
    Australia Australia
    jbsmathers:

    OK, even though I don't keep up to date on what the different programs (HIP, Girder, EventGhost, etc...) are doing these days, I'm pretty sure the following is true... (please correct me if I'm wrong)

    There are two ways to access the MCE device, through it's HID driver or by directly communicating with it. If you want to blast IR commands then you need to directly communicate. Any software that only uses the HID driver can work with the default eHome driver of either Windows XP or Vista, but can't blast IR commands.

    I'm not sure how EventGhost is doing it these days, but I think it just uses the HID approach, so it should work with the default driver on either Windows XP or Vista, but not be able to blast IR.

    Hip and Girder need the replacement driver when used on Window Vista. On Windows XP they don't.

    Actually, I'm not 100% sure about the latest version of Girder... I haven't touched Girder in ages. But what I've said definitely applies to earlier versions and I'd be surprised if it had changed.

    IR Server Suite does not need the replacement driver when used on Windows XP or Vista, and it can Blast IR commands.

    In summary (correct me if I'm wrong guys):

    1. For all Windows XP users the Replacement Driver is obsolete, no matter what software they use (HIP, Girder, EventGhost, etc ...), they can just remove the registry keys and it will behave like the replacement driver.
    2. For all IR Server Suite users the Replacement Driver is obsolete (Windows XP and Vista). And you can blast IR.
    3. For all EventGhost users the Replacement Driver is obsolete (Windows XP and Vista). But you cannot blast IR.
    3. Windows Vista users that don't want to use IR Server Suite or EventGhost will still need to install the Replacement Driver (for HIP, Girder, etc...)

    There are some minor exceptions:

    1. Some 3rd party devices made for Vista seem to work under XP if you use the replacement driver.
    2. 64-bit Windows XP/2003 users are still waiting for a 64-bit replacement driver because they don't have a "default" driver. I can't believe no-one has taken the replacement driver source code and made it work...
    3. Vista 64-bit users can't use HIP or Girder because there is no 64-bit replacement driver. They can however use IR Server Suite or EventGhost.

    Now, the mceir.dll file is used to communicate with either the default eHome driver (XP only) or the Replacement driver (XP or Vista).

    HIP and Girder (at least the older versions) both use the mceir.dll to communicate with the device... therefore, they will work with the default driver on XP or the replacement driver on XP and Vista.

    The same mceir.dll can be used throughout, there is no difference between using it for HIP or Girder.

    I hope that answers all your questions?

    Cheers,
     
    Status
    Not open for further replies.

    Users who are viewing this thread

    Top Bottom