|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Fri Aug 06, 2010 7:37 pm Post subject: RM 1.99b errors (Win 2000) |
|
|
I've been having problems getting RM 1.99b to work in Windows. It runs just fine in Linux (Ubuntu 10.04) and on the Mac (OS X 10.6.4), so the problem isn't a corrupted download.
I suspected something was amiss when I double-clicked the Setup.vbs and got the following (in a "Windows Script Host" alert box):
Code: |
Script: C:\Program Files\JP1\rm199b\Setup.vbs
Line: 37
Char: 1
Error: Invalid root in registry key "HKCR\jar_auto_file\shell\open\command\"
Code: 80070002
Source: WshShell.RegRead
|
I can run RM via the command line, so I may just create a couple of .bat files and link the icons to those instead, so I don't have to open a command prompt every time.
I'm guessing the real problem may be with some of my anti-spyware programs (particularly Spybot-SD); I've never been able to run RM by double-clicking on RemoteMaster.jar either...the result in that case is always a Spybot alert box stating "Nothing found"! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Sun Aug 08, 2010 11:08 pm Post subject: Re: New Setup.vbs, and a different question |
|
|
Sorry for the delay...Works just fine, thank you. No problems from Spybot, either. Granted, I've also updated Java to 6.21...
Off topic: Since FTDI has a driver for Mac OS X, and RM (and RMIR) run just fine there, is anyone game for porting DecodeIR--the sole remaining piece needed for IR functionality, AFAIK--to the Mac? (One would also need Tommy's JP1.x cable and JP1.x-to-JP1 adapter, since Delcom's Mac driver has apparently been removed, no Mac since the now-ancient Beige G3 models has a serial port, and, apart from some of-historic-interest-only custom configurations, no Mac has ever had a parallel port.) |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Mon Aug 09, 2010 7:59 am Post subject: |
|
|
Glad to hear the new Setup.vbs has resolved your issues. It'll be rolled into the next release.
As for OS X support, we need help. The first thing we need is for someone to copy'n'paste the contents of RMIR's Help > About dialog into a post.
You say RMIR runs fine on OS X, but does that include up/downloading? Have you installed the FTDI driver for OS X?
I've read that there's a chance the Linux builds of DecodeIR and possibly even the JP1.X interface code will work on OS X. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Mon Aug 09, 2010 10:50 am Post subject: Re: OS X support |
|
|
Quote: | You say RMIR runs fine on OS X, but does that include up/downloading? Have you installed the FTDI driver for OS X? |
"Runs fine in OS X" means that RMIR will load, edit and save IR files, and of course also load, edit and save RM/KM upgrades and add them to (or remove them from) RMIR. Also, the edited IR files can then be moved back into my Windows VM (or a real Windows PC), opened in RMIR (or IR), and uploaded into a remote. I haven't installed the FTDI driver, since I don't have Tommy's cable and adapter (both my remotes, a URC-6800 and URC-8910, are EEPROM-based, so I would need both). I'm using the Delcom cable.
From what I've seen, Tommy's stuff is slick, and a single solution for JP1 and JP1.x would be nice, but $50 is a little beyond my means at the moment.
Quote: | I've read that there's a chance the Linux builds of DecodeIR and possibly even the JP1.X interface code will work on OS X. |
In that case, all we need is someone with an Intel Mac and the cable for testing. (Ideally, this person would also have Windows or Linux, in case his/her remote's contents got mangled and needed a restore.)
Porting to the Mac is complicated by the fact of two--no, three architectures: PowerPC (the old G3/G4/G5 boxes; these run earlier versions of OS X, from 10.2.8 "Jaguar" to 10.5.8 "Leopard"), 32-bit x86 (the very first Intel Macs, using Core Solo/Duo; these can run the current "Snow Leopard," albeit in 32-bit mode), and 64-bit x86 (aka amd64; all current Macs, starting with the Core2 Duo-based machines). The 64-bit machines can use 32-bit drivers and libraries, but must be booted in 32-bit mode to do so.
The good news is, since the Linux libraries are already available in both 32- and 64-bit flavors, that part is done...assuming they will work at all. (PPC Macs would be SOL here.) I don't know if the FTDI driver is "universal" or not; if so (or if separate 32- and 64- bit versions are included), then that hurdle is cleared as well. |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Mon Aug 09, 2010 7:06 pm Post subject: Re: About box |
|
|
As stated above, in Snow Leopard, RMIR will run OK, edit IR files, etc., but no interfaces are available in the "Remote" menu, and the "upload" and "download" buttons are grayed out. Here's what the About Box shows:
Quote: | RemoteMaster v1.99b
Written primarily by Greg Bush, now accepting donations at
http://sourceforge.net/donate/index.php?user_id=735638
RDFs loaded from /Users/(redacted)/RemoteMaster/rdfs
Images and Maps loaded from /Users/(redacted)/RemoteMaster/maps
DecodeIR is not available!
System Properties:
•java.version = "1.6.0_20"
•java.vendor = "Apple Inc."
•os.name = "Mac OS X"
•os.arch = "x86_64"
Libraries loaded from /Users/(redacted)/RemoteMaster/Mac OS X-x86_64
|
I took a look at the rmaster.err file; from it, I surmised that (a) RMIR wanted to use the 64-bit libraries, (b) it expected to find them in a folder called "Mac OS X-x86_64", and (c) it expected them to have an extension of ".jnilib". I changed the file and folder names accordingly, and re-ran RMIR. Here's what I found at the end of rmaster.err:
Code: | libraryFolder=/Users/(redacted)/RemoteMaster/Mac OS X-x86_64
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib
Unable to create JP1Parallel object: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib: no suitable image found. Did find: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1parallel.jnilib: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib
Unable to create JP12Serial object: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib: no suitable image found. Did find: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp12serial.jnilib: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1usb.jnilib
Unable to create JP1USB object: Can't load library: /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libjp1usb.jnilib
Loading /Users/(redacted)/RemoteMaster/Mac OS X-x86_64/libDecodeIR.jnilib
DecodeIR JNI interface not found! |
Again, since Macs have no provision for a parallel port, the "libjp1parallel.jnilib" file would be unnecessary. OTOH, the Delcom-based interface would probably require writing a new driver from scratch.
If the source for the Linux libraries is available, would a simple recompile in OS X do the trick? I do have Xcode and the gcc/gcc++ suite installed, and could probably generate the 32- and 64-bit Intel (and possibly the PPC) binaries.
Last edited by alex750 on Tue Aug 10, 2010 7:50 pm; edited 1 time in total |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Tue Aug 10, 2010 7:44 pm Post subject: Porting RM libraries to Mac OS X |
|
|
Got the source code and took a look at it. Apart from the actual C++ files and their headers, a folder called "com" which contains some Java stuff (the glue code for RM, I'm guessing), and a Unix-style makefile, there were several files starting with "DecodeIR" of unknown purpose that, on further examination, turned out to be MS Visual C++ project files. I'm assuming these are unnecessary for our purpose.
Anyway, the makefile was as follows:
Code: | NAME=DecodeIR
JAVA_INCLUDE=/usr/lib/jvm/java-6-sun/include
INCLUDES=-I$(JAVA_INCLUDE) -I$(JAVA_INCLUDE)/linux -Icom/hifiremote/decodeir
all: lib$(NAME).so
clean:
rm lib$(NAME).so
lib$(NAME).so: $(NAME).cpp
g++ -shared -fPIC -o $@ $(INCLUDES) $? |
Here I ran into a snag. Mac OS X keeps its Java libraries elsewhere, which I discovered to be /System/Library/Frameworks/JavaVM.framework. In there are no fewer than seven symlinks, plus a directory called "Versions" with yet more symlinks--and one folder called "Current".
Chasing these symlinks, I found what I believed to be the proper paths, and edited the makefile accordingly:
Code: | NAME=DecodeIR
JAVA_INCLUDE=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
INCLUDES=-I$(JAVA_INCLUDE)/include -I$(JAVA_INCLUDE)/lib -Icom/hifiremote/decodeir
all: lib$(NAME).jnilib
clean:
rm lib$(NAME).jnilib
lib$(NAME).jnilib: $(NAME).cpp
g++ -shared -fPIC -o $@ $(INCLUDES) $? |
opened the Terminal, went to the DecodeIR source directory and ran "make". This was the result:
Code: | g++ -shared -fPIC -o libDecodeIR.jnilib -I/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/include -I/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib -Icom/hifiremote/decodeir DecodeIR.cpp
In file included from DecodeIR.cpp:4:
StdAfx.h:17:21: error: windows.h: No such file or directory
StdAfx.h:18:20: error: crtdbg.h: No such file or directory
DecodeIR.cpp:16:21: error: JNIUtil.h: No such file or directory
In file included from DecodeIR.cpp:5:
DecodeIR.h:43: error: expected initializer before ‘DecodeIR’
DecodeIR.h:57: error: expected initializer before ‘ProtocolSupportLevel’
DecodeIR.h:59: error: expected initializer before ‘EnumerateProtocols’
DecodeIR.h:61: error: expected initializer before ‘Version’
DecodeIR.cpp:681: error: expected initializer before ‘compare’
DecodeIR.cpp: In member function ‘void Signal::decodeX(int)’:
DecodeIR.cpp:734: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::decodeX2(int)’:
DecodeIR.cpp:749: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘int Signal::checkDecodeX(int, int, float, float, float)’:
DecodeIR.cpp:763: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘int Signal::decodeRaw(int)’:
DecodeIR.cpp:791: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::tryGap()’:
DecodeIR.cpp:1089: error: ‘_ASSERT’ was not declared in this scope
DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments
DecodeIR.cpp: At global scope:
DecodeIR.cpp:5302: error: ‘BOOL’ does not name a type
DecodeIR.cpp:5379: error: expected initializer before ‘EnumerateProtocols’
DecodeIR.cpp:5681: error: expected `}' at end of input
make: *** [libDecodeIR.jnilib] Error 1 |
Note that "windows.h" on line 4--what's the Mac equivalent of that?
EDIT: I've looked at the source files; it looks as if I'll need to add additional "ifdef" sections for Mac. Trouble is, I have no clue how to translate these. |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Wed Aug 11, 2010 6:13 pm Post subject: Success, I believe...! |
|
|
Quote: | You might be able to get away with changing all
#ifdef __linux
to
#ifndef _MSC_VER
and
#ifndef __linux
to
#ifdef _MSC_VER |
Done. Re-ran "make", and actually got a finished libDecodeIR.jnilib, but with this warning:
Code: | DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments |
When I ran RemoteMaster with the new library in place, I checked the about box...It now says "DecodeIR version 2.41", as it should.
Now, since I don't yet have libjp12serial.jnilib (or libjp1usb.jnilib!), how do I check to see if DecodeIR is working properly? Perhaps I could try cutting-and-pasting a raw EEPROM dump (from the "Raw" tab in IR.exe or RMIR) from Windows? _________________ Remotes: URC-6800 "Cinema 6L", URC-8910 ("hat switch" style)
RCVR: Yamaha HTR-5440 VCR: JVC HR-VP782U (NTSC) TV: Elgato EyeTV Hybrid (NTSC/ATSC)
Media server: Western Digital WD TV Live Other: iHome IH5 iPod clock radio, Whirlpool window A/C |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Thu Aug 12, 2010 4:27 am Post subject: Re: Success, I believe...! |
|
|
alex750 wrote: | Done. Re-ran "make", and actually got a finished libDecodeIR.jnilib, but with this warning:
Code: | DecodeIR.cpp: In member function ‘void Signal::tryTDC()’:
DecodeIR.cpp:3169: warning: format not a string literal and no format arguments |
|
That line in DecodeIR calls sprintf but with only two arguments. This normally would be done with the second argument being a string literal, and the effect would be the same as strcpy. In this case the second argument is a conditional expression that evaluates to a string, which is equally valid. I think the warning is really suggesting that with only two arguments it would have been better to use strcpy instead of sprintf. This is true, it would have been better. I don't know why I used sprintf - I suspect that at some point I was doing things differently and did use format arguments instead of the long and complicated conditional expression it uses now.
Try replacing "sprintf" by "strcpy". Just that, without changing anything else in that statement. My guess is that the warning will disappear.
If it all works, I will want to make the necessary changes (including this one) in the master copy of the source file. Did you do anything other than what Greg suggested, and now mine as well? _________________ Graham |
|
Back to top |
|
|
alex750
Joined: 14 Sep 2003 Posts: 70 Location: Fayetteville AR USA |
Posted: Fri Aug 13, 2010 11:39 pm Post subject: DecodeIR is ready |
|
|
Quote: | Try replacing "sprintf" by "strcpy". Just that, without changing anything else in that statement. My guess is that the warning will disappear. |
Done. It now compiles without error. Other than that, the changes suggested by gfb107, and the changes to the makefile noted above, only one other change was made to the makefile: an "-arch" option was added to the last line invoking gcc++, for compiling 32-bit Intel ("-arch i386") and PowerPC ("-arch ppc") versions on my 64-bit Intel ("-arch x86_64") MacBook.
I have tested DecodeIR with learned signals using the F12, JVC, NEC1 and NEC2 protocols, cross-checked with IR.exe. So far, so good.
The modified source is here.
The binaries (for all three architectures stated above) are here.
EDIT: Above link to binaries now points to current version, which includes jp12serial. _________________ Remotes: URC-6800 "Cinema 6L", URC-8910 ("hat switch" style)
RCVR: Yamaha HTR-5440 VCR: JVC HR-VP782U (NTSC) TV: Elgato EyeTV Hybrid (NTSC/ATSC)
Media server: Western Digital WD TV Live Other: iHome IH5 iPod clock radio, Whirlpool window A/C
Last edited by alex750 on Tue Aug 17, 2010 7:03 pm; edited 1 time in total |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|