JP1 Remotes

I am trying to install the 2116ex2 extender with IR 5.03. I can get this to work just fine running extinstall from a command line, but when I try to do what I think is the comparable operation from IR, IR hangs.

I initially tried using the IR "Convert file for extender" function with my existing IR text file (MyRemote.txt) in one directory and the 2116ex2.hex file in another, both different than the directory in which IR and extinstall.exe are located. Thinking that the different directories might be the problem, I located what I think are all of the necessary files (ir.exe, extinstall.exe, the RDF files, 2116ex2.hex, and MyRemote.txt) in the same directory. IR still hangs when I attempt the "Convert file" operation.

I can work around the problem by running extinstall outside IR, but it seems a shame not to be able to use the integrated functionality. Please let me know what kind of information I might need to provide to troubleshoot the problem. Thanks.

Chasman

This sounds like a similar problem that I had with the Beta version that was fixed. Make sure you are running the actual released version 5.03. Or for that matter go to 5.04 and it should solve the problem.

No, I was definitely using the released version of 5.03. I am now using version 5.04 and am having exactly the same problem. It occurred to me that spaces in file names might be causing the problem, so I made sure that none of the file or path names involved in the conversion contained any spaces. No joy.

Does the version of extinstall I am using make a difference? I am using using the installation from extInstall_3.zip, assuming that is the most recent.

Thanks.

Chasman

A bit more information...

Running extinstall.exe directly from the command line, I've realized that the RDF files must be located in the current directory. The notion of "current" directory is clear when running from the command line, but not at all clear when running from IR. I have my shortcut to IR set up to define the current directory as that out of which IR runs, which is also where the RDF files are located, but that doesn't seem to matter.

extinstall doesn't appear to care where the files it uses (the extender hex file, the input file, and the output file) are located or whether the file names contain spaces, as long as the RDF files are located in the current directory.

I don't know whether any of these observations make a difference, but I thought I would contribute what I could, since I have no visibility into how IR works.

Extinstall and both RDF's need to be in the same directory. As you noticed, the other files can be anywhere. The directory with the RDF's and Extinstall also needs to be the one IR knows as the RDF directory. So, if you have never set the RDF path in IR or Extinstall is not with the RDF's that may be the problem.

As I mentioned earlier, I have tried a test case where everything (ir.exe, extinstall.exe, RDF files, 2116ex2.hex, and unextended.txt) are in the same directory, and IR still hangs, even if specifying the same directory for extended.txt. Also, the RDF path is and always has been the same directory in which ir.exe resides.

I finally got extinstall to run from IR, but only under the following circumstances:

1) ir.exe, extinstall.exe, RDF files, and unextended.txt must be in the same directory.

2) The name of the path containing the files must not have spaces. I was using C:\Program Files\IR and changed to C:\IR.

3) In IR, the name of the path to the RDF files must not contain spaces. During testing, I had all files duplicated in C:\Program Files\IR and C:\IR and left the RDF path set to C:\Program Files\IR while working in C:\IR, thinking that it should work. It didn't.

Perhaps I'm being too demanding, but I would expect there to be no more constraints running extinstall from IR than running it from the command line. Specifically:

1) extinstall.exe should be installed in the same directory as the RDF files, but not necessarily the same as ir.exe. Since IR knows the RDF path, it should know where to find extinstall. (By the way: Currently, if IR cannot find extinstall.exe, it displays the error message "Missing ExInstall.exe" rather than "Missing ExtInstall.exe" [note the missing "t"]).

2) The extender hex file should be able to reside in any directory (currently, it appears that it can).

3) The file being converted (unextended.txt) should be able to reside in any directory.

4) The converted file (extended.txt) should be able to be created in any directory.

5) Any related path names (RDF path and all files) should be able to contain spaces.

Just my two cents worth. I would be happy to make the changes, if I had the source for IR, though I probably don't have the necessary tools to rebuild it. Comments welcome.

The big difference between running via IR and standalone is when running standalone you don't have to specify the folder since you are already in it. So, it sounds like the main problem is spaces in the file name.

chasman1964 wrote:1) extinstall.exe should be installed in the same directory as the RDF files, but not necessarily the same as ir.exe. Since IR knows the RDF path, it should know where to find extinstall. (By the way: Currently, if IR cannot find extinstall.exe, it displays the error message "Missing ExInstall.exe" rather than "Missing ExtInstall.exe" [note the missing "t"]).

That is the way it works. As long as Extinstall.exe and the RDF's are in the same folder and the IR RDF location is explicitly set for that folder it works. IR has to be explicitely set for the folder where the RDF's are and Extinstall.exe currently REQUIRES the RDF's to be in the same folder. If the RDF path is not set in IR it defaults to the same folder IR itself is in.

Paul can to fix the typo in the error message with the next release.

chasman1964 wrote:2) The extender hex file should be able to reside in any directory (currently, it appears that it can).

Correct, it can

chasman1964 wrote:3) The file being converted (unextended.txt) should be able to reside in any directory.

It can

chasman1964 wrote:4) The converted file (extended.txt) should be able to be created in any directory.

Currently it defaults to the same folder as the input .txt file.

chasman1964 wrote:5) Any related path names (RDF path and all files) should be able to contain spaces.

I thought it did so Paul needs to check on that. I guess we didn't notice that since most of us use simple names like c:\jp1, c:\jp1\RDF etc.

I hope to fix most of these issues when we rewriet ExtInstall and IRToWav as dll's.

All I could do for know was to call the app as is. Extinstall is particular about paths and locations. That is why I had to build the interaction as I did.

BTW the release notes explained about the location of the files:

IR Release 5.03 Notes

This release supports converting standard IR files to the extender version using the ExtInstall. For this to work the ExtInstall.exe and the RDF’s must be in the same directory. This includes the normal and the extended version of the RDF’s in question.

To use this feature open the .TXT version of the IR file (currently ExtInstall only supports this version) then select File | Covert File for extender. Follow the instructions for selecting the Hex definition file and the location and name for the output file. The new file will be automatically loaded in IR upon completion of the conversion.

Follow up:

I just tried it with spaces in the folder names and had no problems..

OK, I am greatly confused. Based on your feedback, the setup I was trying to use should work, but it doesn't. Here are all of the specifics:

-> ir.exe, extinstall.exe, and all of my RDF files are located in C:\Program Files\IR.

-> My RDF path in IR is set to C:\Program Files\IR.

-> My working directory for remote stuff is C:\Documents and Settings\Charlie\My Documents\Remote Control Programming. When I start IR, I open the file "My Remote Unextended.txt".

-> If at this point I attempt to convert the file with "Convert file for extender", I get the "Missing ExInstall.exe" error pop-up. I can get past this problem by copying extinstall.exe into my working directory.

-> Continuing with the copy of extinstall.exe in my working directory, I attempt to "Convert file for extender" again. This time, I am prompted for the hex file. I select C:\Program Files\IR\15-2116ex2\2116ex2.hex.

-> I am next prompted for the name of the converted file. I select C:\Documents and Settings\My Documents\Remote Control Programming\My Remote Extended.txt" (i.e., create the file "My Remote Extended.txt" in my working directory).

IR hangs.

Writing all of this out, I concede that the problem may have to do with path name lengths and have nothing to do with spaces. I could test that theory, but I hate to keep running so many tests when I'm just guessing at the cause of the problem.

Anyway, if the intent is to rework all of this using DLLs, perhaps it is not worth anyone's time to pursue this further, though I don't object in the interests of helping others out there that may be running into the same problem.

Also, for what it's worth, I am running the program on Windows XP Professional from an administrative account. I can't imagine what difference that should make, but you never know...

chasman1964 wrote:-> I am next prompted for the name of the converted file. I select C:\Documents and Settings\My Documents\Remote Control Programming\My Remote Extended.txt" (i.e., create the file "My Remote Extended.txt" in my working directory).

IR hangs.

Is that a typo in your post?. Your working directory is "C:\Documents and Settings\Charlie\My Documents\Remote Control Programming", correct? Or, are you manually entering an incorrect pathspec?

Writing all of this out, I concede that the problem may have to do with path name lengths and have nothing to do with spaces.

Windows imposes a 218 character limit on fully qualified filenames, but I don't see that as a problem here since that's only 88 characters long (unless something internal to the IR-ExtInstall process is choking).

Mark Pierson wrote:Is that a typo in your post?. Your working directory is "C:\Documents and Settings\Charlie\My Documents\Remote Control Programming", correct? Or, are you manually entering an incorrect pathspec?

No typo. All of the path names are exactly as they occur on my computer.

Mark Pierson wrote:Windows imposes a 218 character limit on fully qualified filenames, but I don't see that as a problem here since that's only 88 characters long (unless something internal to the IR-ExtInstall process is choking).

If path name length is an issue at all, I assumed that it would be an array length limitation in the portion of IR that sets up and calls ExtInstall. I'm only suggesting some things that have bitten me in the past when doing Windows programming. Without source code, I'm only guessing.

OK. This problem is becoming an obsession, but I think I have a better handle on it now. At this point, I'm certain the path name length is not the problem. However, I'm more convinced than ever that there are problems with spaces in path names, but only in some of them.

Here are the issues as I currently see them:

1) extinstall.exe must be in the same directory as the file being converted, or else I get an "ExInstall Missing" error. This happens even after I make sure that all of my path names have no spaces.

2) The RDF path name in IR cannot have spaces.

3) The path to the extender hex file cannot have spaces.

The path and/or file names of the file to be converted and the converted file may have spaces.

Also, it appears that the reason for the hang is that IR waits indefinitely for the converted file to be created by ExtInstall. If the converted file already exists when the conversion is attempted, the conversion appears to complete even under conditions where it normally would hang. I verified in this "appears to complete" scenario that the timestamp on the file was from its earlier creation and not from the current conversion attempt. I was also able to get IR to "unhang" by creating the converted file manually.

I'm pretty confident that there is merit to my findings, and I hope that someone else is able to duplicate my results.

1) extinstall.exe must be in the same directory as the file being converted, or else I get an "ExInstall Missing" error. This happens even after I make sure that all of my path names have no spaces.

As I said before

IR Release 5.03 Notes

.......... For this to work the ExtInstall.exe and the RDF’s must be in the same directory. This includes the normal and the extended version of the RDF’s in question.

The file being converted and the output file can be anywhere. The only restriction is ExtInstall and the RDF's. (This is how Extinstall was coded)

2) The RDF path name in IR cannot have spaces.

On my machine: c:\jp1\All RDFs....works fine

3) The path to the extender hex file cannot have spaces.

On my machine: c:\jp1\All Bin....works fine

Also, it appears that the reason for the hang is that IR waits indefinitely for the converted file to be created by ExtInstall. If the converted file already exists when the conversion is attempted, the conversion appears to complete even under conditions where it normally would hang. I verified in this "appears to complete" scenario that the timestamp on the file was from its earlier creation and not from the current conversion attempt. I was also able to get IR to "unhang" by creating the converted file manually.

One of the main reasons to use a DLL instead of an EXE. On a DLL one can programtically return a completed value. Can't do that with an EXE. Therefore the calling program has to have a loop that checks if the file is there and if it can be opened. This then signifies that ExtInstall has released the file and it is complete. So if you use the same name as a previuosly converted file, IR has no way of knowing that it already existed and assumes that ExtInstall is complete.

I'm pretty confident that there is merit to my findings, and I hope that someone else is able to duplicate my

As you can see we are trying to figure this out....there is noithing more frustrating to a developer than when unique issues show up an a users machine and can't be duplicted on a development machine...