ir.exe issue(s)

[ToonGal]

(Imported from another thread, to avoid going too off-topic there)

Originally posted by ToonGal
With URC-8810w in hand and JP1'd, my personal problem is now the Hauppauge IR.exe program keeps needing to be restarted for some reason...

Originally posted by Opus4
what is happening that requires restarting IR.exe? A few points for now:

• It seems like the [] sections are limited in the number of entries they can have, though at first I thought it was 64, then 128, & now I'm not sure. Perhaps it varies according to the type of section it is. It doesn't crash, though; it just ignores the extra settings.
  
• IR.exe doesn't seem to like too many different system codes being defined. Crashed at startup when I did that.
  
• If you are using mode(appname) to switch control to certain sections, are you remembering to use mode() or mode(Default) to get it back under control when you close that app? If you are stuck in some mode, it may appear that it no longer works properly.

The main issue is that the ir.exe seems to pick the commands from an incorrect [] section after some 'event' (unknown exactly what) occurs. To address your specific points:
- [] sections seem to have random length for commands. It doesn't seem to be total # of commands, nor space used by commands. Probably some assembly thing. Not the issue, because I already have run into this in my 'debug.txt' section. Restarting IR seems to fix things immediately, so not an irremote.ini config issue.
- Only two system codes (HCW PVR remote and OFA) and doesn't seem to overload it.
- Manually selecting the window (via mouse over VNC) to establish the focus doesn't even give it control. From what I understand, mode() just sets the focus, so if it doesn't work when highlighted by the mouse, can't be the issue.

Random thoughts:
- I have redefined the tokens and ordered the file to be more 'readable' and more easily maintained.
- I have organized the tokens to HCW, OFA, and 'both'. I did it to both minimize tokens, address common functionality, and maintain compatibility with both remotes.
- I have obliterated all WinTV program references. I converted them initially, and it all worked, but archived it to an external file, as bloat isn't generally useful.
- My most common occurrance of this problem happens when I use MPC (Media Player Classic). However, this is highly possible that it correlates to highest program use.
- Running 'Restart IR' immediately cures all evils. I have some buttons on the OFA dedicated to global 'default' use and am thinking of adding this there to solve the problem. If it just thinks the wrong [] is active in the .ini file, a global run() to Restart IR might do the trick. Completely artless, but functional.

@Opus4:
JP1 on the OFA going extremely well, Opus. All individual components solved, and last issue in play on the JP1 boards. Thanks again, hun.

[Opus4]

Originally posted by ToonGal
The main issue is that the ir.exe seems to pick the commands from an incorrect [] section after some 'event' (unknown exactly what) occurs.

See my 3rd point, above, regarding the use of the mode() command. You've got a few mode() commands in the default section, but only the SageTV section resets it back to Default when you exit/sleep the program. This means you are getting stuck in some modes & are possibly sending gibberish key commands to other apps when they get Windows focus -- some of those keys may cause _something_ to happen, but it may or may not be the _something_ you wanted.

From what I understand, mode() just sets the focus

Mode() has nothing to do with setting Windows focus. All it does is tell IR.exe which section to _always_ use for command interpretation, regardless of what program currently has Windows focus. Any commands not defined in that section are then interpreted via [Default]. If the command isn't in either section, it would be ignored, as far as I can tell.

You don't actually have to use mode(), but I found that it made my life easier. If you wish, simply remove all mode() commands and IR.exe will translate commands according to the section name that matches the window that has focus. One possible problem: some apps change the window name... kind of hard to match those, so you would be stuck using mode() for those apps.

So... mode(SectionName) forces commands to be interpreted from [SectionName]. Use mode() to reset the mode to work as 'normal': interpret according to the name of the window that has focus. Thus, once you use mode(SomeApp), you have to use mode(SomeOtherApp), mode(Default), or mode() when you exit that program.

Also note that if you use some app as a menu program, it cannot automatically change IR.exe's mode -- so if you are using mode() commands & you use the menu app to run SageTV, it won't know to also do a mode(SageTV) & you will end up sending the menu program's key commands to SageTV.

I think that changing your use of mode() will solve most, if not all, of your problems.

Other comments:

Be sure you are running the latest Hauppauge IR drivers/software. Go to SHS's site and click on Download, select your tuner, then download the IR Remote Control file -- current version is 2.35.21321.

Are your other device buttons on the 8810 used already? (I don't know how many device buttons that one has.) I use a different device for each of my IR-controlled apps & each device uses unique RC5 codes, so none are shared with the other apps. Then, each app has its own unique Power ON/OFF buttons so that I can use them to activate another app while one is already running. It looks like you are controlling more apps than I am, so while you may not be able to assign completely separate RC5 system codes to each app, you could certainly consider using other device buttons to extend your control.

Unique RC5 codes are not really needed -- you just have to be careful about which buttons you use to activate each app in the Default section, make judicious use of the mode() comamnd, & so on.

That's my diagnosis... hope it is right.

- Andy

[ToonGal]

Removed all mode() commands but to no avail. After playing around a little, I think I might have figured out a major potential issue. My file naming conventions are "BetweentheLions-LionelsGreatEscapeTrick-292034-0.mpg" for SageTV files and "Between The Lions - 1x01 - Pecos Bill Cleans Up The West [ToonGal].mpg" for edited versions of SageTV shows.

As a result, when I used MPC, it had a massively long title bar, and the "Media Player Classic" title bar was buried under the depth of the detail with the file name. I'm guessing that searching through such a long title crushed the window searcher.

After changing MPC to "Don't prefix anything" and only displaying "M P C" on the title bar, I seem to have eliminated a lot of issues.

Will post again if the issue shows up again, with more detail on exact circumstances it fails. The MPC one seems to be solved.

Thanks again, Opus!

[ToonGal]

I've now isolated this as two separate issues: one major, one minor, but both semi-resolved.
1) Major: After a delay, the specific [program] sections no longer seem to function; only the [Default] one seems active.
2) Minor: Some windows (in my case, MPC=Media Player Classic) have such long names that they get lost in the [program] section name.

Solutions:
1) The following code is my main [Default]. I've seen at least one other user who runs Restart IR with every main .exe he runs. This would solve his problem too. I allocate a key to be the Restart IR, so when general keys seem unresponsive, the likely solution is that it is in [Default] mode. To me, this happens most often after a long delay between usages. No idea why this happens, but after a Restart IR from the remote, all other buttons / [sections] work again.

[Default]
; Default - default definitions for remote
KEY_ALL_POWER={run(C:\Progra~1\WinTV\Ir.exe /QUIET)}
KEY_ALL_BUTTON1={run(C:\Progra~1\myHTPC\myHTPC.exe)}
KEY_ALL_BUTTON2={run(C:\Progra~1\FreyTe~1\SageTV\SageTV.exe)}
KEY_ALL_BUTTON3={run(C:\Progra~1\totalcmd\TOTALCMD.EXE)}

2) Basically, ensure that window titles are the minimal length. I remove all extra information from the title bar to make finding the app easier. In the case of MPC, merely removed all file name playing information from the title. There were multiple programs (WMP, etc.) that had this issue, but was easy enough to configure / resolve.

[Opus4]

Hmmm... I wonder if there is some sort of bug in IR.exe... perhaps you are right about the very long window title causing a problem.

You've removed _all_ the mode() commands, including the one used when you put SageTV to sleep? Your SageTV section had:

KEY_ALL_POWER={ctrl}z{mode(Default)}

If that is still there, you are eventually forcing the thing into default mode permanently.

I use mode() to force the use of various sections for every program I use & run it for days w/o having to restart. (I'm not saying that you can't have problems just because I can do that... simply reporting my results. You may be controlling more programs than I do, possibly causing problems I don't see.) My FM radio program changes the Window title every time I change stations, but it continues to work. If you wish to try using mode() again, I would suggest setting aside unique IR codes for starting each app, which I think you already do, then when you hit the start button for some program, its definition in the [default] section would run the exe (should just bring it into focus if already running), and set the mode to that program's section. When it exits, it would set the mode back to mode(default) or mode().

That way, every time you start a program, it would force IR into its mode & also has the side effect of giving the program Windows focus when you press its start button (if running the exe brings it into focus). No need to exit a program just to start another one, either.

There is a sort-of debugging trick I can think of: set aside one IR code as your debugging code. In every section, define it as something like:

KEY_DEBUG=section name{enter}

Then, when the remote seems unresponsive, start Notepad, press the debug key on your remote & see what happens. If it is stuck in some particular [section], you will see its name appear.

- Andy

[ToonGal]

- Removed all mode() commands
- Unique keys in [Default] to start main progs (myHTPC, Sage, Total Commander) and one for Restart IR during [default] issues
- Neat trick on the [section] part. Just added L4 for this

Attached the current file, but not much new. Haven't had the problem since I cut down on the MPC issue 100%.

[Opus4]

I've been meaning to add this to the things to be tested with irremote.ini -- load a file with a _really_ long name into Notepad & see if that messes things up. However, I haven't had time to do anything with it lately.

Also, you weren't expecting [Media Player Classic] to match a window with a name of something like "Media Player Classic - Some Filename that is playing right now at this instant.mp3" were you? I believe it only does an exact match when comparing "section name" to "window title".

- Andy

[ToonGal]

I also have been too lazy to do a comprehensive test on this, but did have "M P C - filename" at one point working on MPC/ir.exe. The main issue seemed to occur when it was too long a filename. My guess is that they really only do a # of char comparison and not the entire window. For the WMP section, there's a findwin() command they use for that, and I'm guessing that is the proper format to do what I originally tried w/ MPC. I don't miss the titlebar detail, so it's working 100% with the exact match.

Still no occurrances of the 'lost remote' issue either, so maybe it was the mode(default) fix I did when you first mentioned it.

Really wish Hauppauge had ANY details of how the irremote.ini file worked and/or the protocols for ir.exe worked. Once my son starts preschool in Sept, that might be a good project for fun to reverse engineer. Probably more effort than it is worth.

[Opus4]

Originally posted by ToonGal
For the WMP section, there's a findwin() command they use for that, and I'm guessing that is the proper format to do what I originally tried w/ MPC.

I've done some tests with findwin() and have not gotten it to work, even watching the specified window using Spy++. None of the commands I sent were received by the specified window, even when using the exact command text someone at Hauppauge recommended. When I have the time (might be quite a while), I plan to look into findwnd() some more to try to figure out whether a) I still don't understand how to use it, or b) the command is broken in IR.exe.

Still no occurrances of the 'lost remote' issue either, so maybe it was the mode(default) fix I did when you first mentioned it.

Good... I wasn't following whether that problem was fixed by removing the mode() command or changing the title bar text.

Really wish Hauppauge had ANY details of how the irremote.ini file worked and/or the protocols for ir.exe worked. Once my son starts preschool in Sept, that might be a good project for fun to reverse engineer. Probably more effort than it is worth.

After writing my docs, I found a contact at Hauppauge & got some more details. What info are you looking for? Maybe I've got it. I've been told that just about the only documentation they have of how IR.exe/irremote.ini works is the source code comments... or at least that's how I interpretted what I was told. Most of what I was told is already listed in my docs & at Inofficial documentation of the IRREMOTE.INI (by Daniel Schnabel), though a few things were clarified. I've suggested a couple changes, but I have no idea whether they will get added.

What I would really like to be able to do with findwnd() is use it to either send keys to a particular window (SageTV wouldn't need focus in this case), or at least bring the specified app back into focus so it will receive the keystroke.

When you mention "the protocols for ir.exe"... what do you mean? The infrared protocols or something else? The infrared protocol is known: RC5, & that is _all_ the Hauppauge IR receiver can decode in its hardware.

- Andy

[ToonGal]

For "protocols for ir.exe", I meant more the INTERNAL protocols, as to how it internally works, as opposed to the RC5 codes. Figured all that easily enough when you pointed us in the JP1 direction. Knowing the exact limits of the receiver would be good too. Knowing some of the tech specs might be useful, in that you could build a replacement h/w and/or s/w component to replace the one there. (I've seen pretty good do-it-yourself h/w receivers, and might want to play; I also think the s/w could be configured to work w/ my wireless Logitech MX Duo keyboard, which would have add'l keys I could add from the non-k/b part.) Most of this is idle curiousity, although the more it was opened (i.e. less reverse engineering), the more interest I'd have in playing. SageTV SDK would be of utmost interest if v2 had the ability to add external programming helpers; in lieu of that, this seems like an interesting diversion.

I've been particularly annoyed with the wintv2k.exe, wintv32.exe, etc list of programs listed in ir.exe and the reason I can't find the configuration. I pulled out Hackman Hex Editor to break down some of the internals of ir.exe to satisfy my curiousity. I wasn't disappointed. Here's what I found.

Instead of ir.exe being configured by some file/registry entry to load that program submenu, it is actually hardcoded into the app itself. It has (at least) 6 progs available of which I only have two active (listed above). The remaining ones include: radio.exe, wintvcap.exe, snapshot.exe, vtplus.exe.

There is a whole bunch of interesting things inside this program.

[Opus4]

Originally posted by ToonGal
For "protocols for ir.exe", I meant more the INTERNAL protocols, as to how it internally works, as opposed to the RC5 codes.

You could always go to the Girder site & download Peter Heitman's source for his Girder plugin that works with the Hauppauge IR receiver -- it has code to interface with the receiver's dll & get the RC5 commands directly. See: Girder's developer download page. Of course, you lose any access to irremote.ini, but you could always 'roll you own'. I've looked at that code & it appears to only support the RC5 codes used by the Hauppauge remotes. It looks like it would be fairly easy to change it to support any RC5 code (possibly even command values from 64-127 too) -- that would make it much more useful for use with Girder, since you could use many more unique codes.

I've been particularly annoyed with the wintv2k.exe, wintv32.exe, etc list of programs listed in ir.exe and the reason I can't find the configuration. I pulled out Hackman Hex Editor to break down some of the internals of ir.exe to satisfy my curiousity. I wasn't disappointed. Here's what I found.

Instead of ir.exe being configured by some file/registry entry to load that program submenu, it is actually hardcoded into the app itself. It has (at least) 6 progs available of which I only have two active (listed above). The remaining ones include: radio.exe, wintvcap.exe, snapshot.exe, vtplus.exe.

Yeah, that one I knew from asking Hauppauge about it recently: the menu brought up by the gomenu() command is hardcoded into ir.exe. You would have to write your own menu program, or try out one mentioned on SHS's forum recently, towards the end of this thread. I haven't looked at it yet, but it might be interesting.

I think you have to look at this from Hauppauge's point of view: I don't know the 'official' story, but my guess is that this was never intended to be a general purpose remote system, but rather simply one to control the products that come with their cards. We're probably lucky that they decided to make things configurable in an ini file. In contrast: I haven't searched much, but my Xcard remote, for example, seems to have everything hard coded into the software & I don't see an easy way to modify any of it. (It may be in some sort of ini file somewhere & I just don't know it.) If the Hauppauge remote system were really intended to be a full scale, general purpose remote system, I think it would, at the minimum, support other IR codes, and more options for application control, including a better way to send commands to an app that does not have focus.

There is a whole bunch of interesting things inside this program.

If you find other interesting things, let me know.

- Andy

[ToonGal]

If you keep contact with a Hauppauge person who codes ir.exe (or knows the programmer), there's a bug in the irremote.ini handling. I am playing with Zoom Player, after many recommendations, and one of their default keys to control a feature is {shift}{home}. This was obviously easy to add to the .ini file, but it was NOT handled correctly by ir.exe. It was ignored. Some preliminary tests show that {shift}, {alt}, and {ctrl} do NOT work with {} commands (like {home}, {end}, etc).

When you say:
KEY1={shift}a
KEY2={shift}{home}
it does not acknowledge the holding of {shift} when executing the {home} on KEY2, but does generate "A" on KEY1.

My guess is the programmer simply looks at the next character and doesn't process the {} commands, just single characters.

I first wanted to clear a text box with my remote, using:
KEYX={end}{shift}{home}{back}
but when that didn't work, I just assumed I did something wrong, and didn't try again. However, even a straight {shift}{home} and {shift}{end} (playlist control) don't work.

For those who care, pleasantly surprised by ZoomPlayer v4b3, and I've been a very biased MPC user forever. Might actually switch if the testing is as positive as the initial reaction.

[Opus4]

Originally posted by ToonGal
When you say:
KEY2={shift}{home}
it does not acknowledge the holding of {shift} when executing the {home} on KEY2

I first wanted to clear a text box with my remote, using:
KEYX={end}{shift}{home}{back}
but when that didn't work, I just assumed I did something wrong, and didn't try again. However, even a straight {shift}{home} and {shift}{end} (playlist control) don't work.

I finally had time to check this... I tried "{shift}{home}" and "{end}{shift}{home}{back}" while editing gibberish in Notepad & it worked perfectly. I also tried the 4 {shift}<arrow keys> and they worked too.

You might want to try again. (Don't forget to restart IR.exe after every irremote.ini edit; I don't know if that was the problem or not.) If it doesn't work... I'm not sure why it would work in Notepad but not another program.

- Andy

[ToonGal]

Originally posted by Opus4
You might want to try again. (Don't forget to restart IR.exe after every irremote.ini edit; I don't know if that was the problem or not.)

Try again, I did. I tried this in notepad (debug.txt) the second it originally failed in ZoomPlayer. It failed again. (And yes, I did restart IR.exe...)

If it works on your system in notepad, and not on mine, then I have to conclude we have different versions. This program is horribly version stamped (i.e. none), so the best I can do is provide detailed md5 info to see if it checks/checksums with yours.

; 102455 11:25.52 2003-04-23 Ir.exe
e4dcafe3b14df98b8bb6f4f402ee975c *Ir.exe

KEY_ALL_FASTREWIND={shift}{home}
KEY_ALL_FASTFORWARD=={end}{shift}{home}{back}

Those are the two lines in [debug.txt] I altered. Strange behavior:
- the FREW acts as a {home} only (no text from cursor to home highlighted)
- the FFWD acts as an {insert "=" at cursor} then {home}

I have NO explanation or clue about the ffwd. Packaging up both ir.exe and irremote.ini for further comparisons. I thought I have the latest version from the SHS site, but again, so hard to tell given the lack of version stamping (another request for Haup if you advise them on improvements).

[Opus4]

Originally posted by ToonGal
KEY_ALL_FASTREWIND={shift}{home}
KEY_ALL_FASTFORWARD=={end}{shift}{home}{back}

Those are the two lines in [debug.txt] I altered. Strange behavior:
- the FREW acts as a {home} only (no text from cursor to home highlighted)
- the FFWD acts as an {insert "=" at cursor} then {home}

I don't know what md5 is, but our ir.exe files are the same. Your 2nd example above has an extra '=', so that is why it is getting inserted into the Notepad file. Beyond that, I'm pretty much lost as to why the same commands worked for me & not for you. I simply added those commands to some of my SageTV commands, made sure I was in SageTV mode, & set the focus to Notepad instead of SageTV... and then any command with {shift} in front of it caused text to be selected. {end}{shift}{home}{back} worked as expected: the whole line was selected & deleted.

If you have an older, simpler irremote.ini (the original ini?), perhaps try the commands in that file. Sorry, but with a quick glance through your ini, nothing immediately jumps out at me.

- Andy

[ToonGal]

Originally posted by Opus4
Sorry, but with a quick glance through your ini, nothing immediately jumps out at me.

You and me both. This is baffling...

Your 2nd example above has an extra '=', so that is why it is getting inserted into the Notepad file.

Tee hee. Silly me. I saw that about 5 minutes after I posted. Didn't affect the real problem, and you found it quickly too. -Sigh-

If you have an older, simpler irremote.ini (the original ini?), perhaps try the commands in that file.

I tried (and included) the bare-bones install version using the Haup remote. Set Rew/FF as the active keys as following in the debug section:
REWIND={shift}{home}
FASTFWD={end}{shift}{home}{back}
Same results. Merely acted as a {home} key.

I don't know what md5 is, but our ir.exe files are the same. Beyond that, I'm pretty much lost as to why the same commands worked for me & not for you.

MD5 is one (of many, like SFV) checksum algorithms that can compare files (text, binary, etc) and verify whether they are identical with a relatively high degree of security. I use hkSFV, at http://www.big-o-software.com. An md5 checksum might be important here, because without a robust mathematical way to compare the .exe files, it is still possible that we have different .exe files. It's the ONLY explanation that makes sense at this point.

I tried the {shift}{home} in notepad, ZoomPlayer, and Sage, just to make sure that I was thorough. Maybe if you could post your .exe if the md5 isn't the same value. I'm lost at this point...

Thanks again for the help, hun.

[Opus4]

Originally posted by ToonGal
An md5 checksum might be important here, because without a robust mathematical way to compare the .exe files, it is still possible that we have different .exe files. It's the ONLY explanation that makes sense at this point.

I didn't worry about a checksum, since I had your exe I could do a comparison of the files -- they are exactly the same. I don't think this should make a difference either, but my irremote.dll is version 2.18.21110.0. That files deals with the receiver, as far as I know, so I don't know how it could affect things, but...

- Andy

Edit: Did I ask whether you downloaded & installed the latest IR drivers on SHS's site? 2.35.21321