JP1 Remotes

mathdon · Posted: Wed Apr 19, 2023 1:22 pm Post subject:

I believe I have fixed both errors. I will post a new build tomorrow after further testing.

@davecs: Your error affects only the URC6440 and US equivalent, as these are the only remotes with segments that have an extender.

@HamburgerHelper1: Your error would affect all JP1.3 and earlier remotes that do not have multimacro buttons. Unfortunately the only JP1.3 remote that I used in testing was an RCRP05B, which I chose deliberately as it DOES have multimacro buttons Rolling Eyes

. I thought the more complicated the remote, the better the test. I have been caught out that way before, but clearly have not learned my lesson Embarassed

.
_________________
Graham

jmezz13 · Joined: 28 Oct 2004 Posts: 94

I have been playing around with my old 8811 and 8910 remotes with 2.15.1 and have run into some issues. However, I don't think they should hold anything up because I also verified the same issues with 2.14.8. And maybe they are already known or operator error.

Long story short I'm getting an "Upload verify failed" message when uploading to either of these remotes with a JP1.x interface. Interestingly, I don't get the error when I use the Delcom interface. If I then try to upload the same file with the JP1.x, it works fine, but trying to load any other file with the JP1.x will fail. If I download after a failed upload, I will see a few bytes that have been changed. Also, one of the files I'm using will cause a failed download with an error message saying there may be a bug in RMIR, etc. All these files were created in 2012-1017 timeframe. Not sure what to make of it.

davecs · Joined: 28 Mar 2005 Posts: 328 Location: UK

May I make a suggestion? As the changes to RMIR have been quite fundamental, with the clash reporting for example, that when this iteration finally becomes an official release, it takes the version number 3.0.0 ?
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

mathdon · Posted: Thu Apr 20, 2023 9:33 am Post subject:

davecs · Joined: 28 Mar 2005 Posts: 328 Location: UK

mathdon · Posted: Thu Apr 20, 2023 1:27 pm Post subject:

jmezz13 · Joined: 28 Oct 2004 Posts: 94

Ran into issue trying to open IR files in 2.15.1 Dev. The IR files open fine in 2.14.18. Applicable excerpt from rmaster.err is here:

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26712

Barf · Posted: Fri Apr 21, 2023 3:37 am Post subject:

mathdon · Posted: Fri Apr 21, 2023 10:10 am Post subject:

I have now replaced RMIR v2.15.1 in the RMIR Development folder with v2.15.2. I believe this fixes the bugs reported by davecs and HamburgerHelper1 but not yet that found by jmezz13. There is definitely something strange with the files posted by jmezz13. The .ir file loads with IR.exe but with lots of messages about clashes and overflow of the data area for Advanced Codes. What is the relationship between the .ir and .rmir files you have posted? Is the .ir file a download from a successful upload of the .rmir file?

@Barf: I don't think it worth creating a branch to cope with a delay of just one day. I've never used branches and not really seen a need for them for RMIR. I thought they were primarily intended for programs being developed by multiple people.
_________________
Graham

jmezz13 · Joined: 28 Oct 2004 Posts: 94

davecs · Joined: 28 Mar 2005 Posts: 328 Location: UK

I have loaded the files created by 2.14.18 in 2.15.2.

In the case of the 6440 file, it was the one I made to put the Special Functions in the same order as how 2.15.1 ordered them when downloaded from the remote, which helped me to trace the errors in that version. Loading it into 2.15.2, resulted in identical Raw Data.

In the case of the 3661 file, there were a small number of bolded entries in a small area, but I was able to trace all of them to a group of 5 special functions being arranged in a different order.

So far, so good. I will upload the latest versions to the remotes and test them when I get access to the TV and stuff later.
_________________
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661

mathdon · Posted: Fri Apr 21, 2023 1:12 pm Post subject:

I have found a bug in using the files posted by jmezz13. If I loaded the .rmir file and saved it as a .ir file, the .ir file would not load. This turned out to be a bug that would affect the downloading, and loading of a .ir file, of JP1.3 and earlier remotes with macros.

I have posted RMR v2.15.3 in the RMIR development folder that fixes this bug.

This version still gives an error when attempting to load the .ir download that jmezz13 posted. That needs further investigation.

The upload error that started with v2.12.5 is probably an issue with jp12serial, as that was updated from v0.24 to v0.25 in that version. I have re-posted jp12serial v0.24 here if you wish to test this.
_________________
Graham

jmezz13 · Joined: 28 Oct 2004 Posts: 94

I tested with 2.15.3 and the 0.24 version of jp12serial.dll.

Opening of IR Files: Works (except for that one quirky IR Raw Download)
Upload of 8811 rmir to remote: Works

The download of that one specific RMIR file fails as you stated it would.

I will also say that version 0.24 of the dll is more finicky about the connection and I had several "Remote not Found" errors after the download error. I restarted RMIR and disconnected/reconnected the JP1.x cable to get it working again.

davecs · Joined: 28 Mar 2005 Posts: 328 Location: UK

mathdon · Posted: Sat Apr 22, 2023 1:18 pm Post subject:

I have replaced RMIR v2.15.3 in the RMIR Development folder with v2.15.4.

This build will load the .ir file posted by jmezz13 that had previously seemed to be intractable. It has been an interesting task to figure out what the problem was. It turned out to be an issue that goes back a VERY long way, to the early days of this forum, affecting IR.exe as well as all versions of RMIR. These all treated key moves in JP1 remotes as having a maximum length of 16, encoded in 4 bits. Maybe no setup had ever been seen whose length exceeded that, but this file had a key move with a length 18, one encoding an LKP special function on XShift-Phantom3, showing that 5 bits were available for encoding the length. This is now supported in v2.15.4.

I don't know how this was created. The special function concerned is present in both the .rmir file and .ir file posted by jmezz13, but in the .ir file its data has two extra buttons, X_DVD Phantom2, that take its length from 16 to 18.

@jmezz13: I am unclear from your last post what the situation now is concerning uploading to the 8811. You say it now works. Is that with jp12serial v0.24 or with the version present in RMIR? The difference between v0.24 and later versions is that it will repeat read attempts on failure, which is why the later ones are "less finicky" about the connection. I was wondering if this behaviour was incompatible with the JP1 EEPROM Adapter that you must be using to communicate with the 8811 with a JP1.x interface. I would be interested to know what adapter you are using, and whether the JP1.x cable is an FTDI one, as I can't really see why there should be any such incompatibility.
_________________
Graham