davecs wrote:1. And now I'm going to ask for a feature request that would have avoided all this!
I noticed that the difference between when the upload worked immediately and when it required me to set the region code, was a single byte in the first segment at 1D814. The data is 00 EE FF FF if it's not set, and 00 EE 01 FF if it's set to Region 1. I tried re-uploading the settings file and once again I had to input the region code. I tried using Preserve Original Data and changed that byte, and re-uploaded again, and everything worked straight away.
So would it be possible, on the General page for the 6440, to add an entry to set the Region Code?
The OARUSB04G doesn't have a Region Code setting.
================================
2. There's one slight fault: When you download from the remote, on the Special Functions tab, the "<none>" entry doesn't appear in the left hand column for any global functions, but it's there in the dialog if you press Edit and reappears if you press OK. I uploaded it straight back up to the remote and it doesn't seem to cause a problem.
3. There's a quirk with the 6440, presumably with the OARUSB04G too, because of the Setup/Copy uses of the WatchTV/WatchMovie buttons. You can't have Long Key Presses on them. You can, however, have Double Key Presses on them.
With the last of these, is it possible to block LKPs on these keys whilst allowing DKPs?
There were three issues in this post earlier on page 9 of this thread. I've added numbers to them. Ignore the other stuff I wrote about the 8910.
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661
1. I have added Region to the Settings panel on the General tab. However, I don't understand the trouble you were having. What was asking you to input the Region code? The remote doesn't have a display on which it could ask this, and RMIR doesn't check the Region code, so I can't see where this message could have come from.
2. Fixed.
3. The URC-6440 and OARUSB04G are the only remotes that use segments for which there are extenders, and so these with an extender are the only such remotes which support LKP and DKP special functions. I have been able to use this to give an error message if a user creates an LKP on the WatchTV or WatchMovie buttons. The message explains that an LKP on these buttons is not possible due to their dual use for Setup/Copy, so that users are not left baffled as to why this is an error.
mathdon wrote:@davecs:
Thank you for your requests.
1. I have added Region to the Settings panel on the General tab. However, I don't understand the trouble you were having. What was asking you to input the Region code? The remote doesn't have a display on which it could ask this, and RMIR doesn't check the Region code, so I can't see where this message could have come from.
When you upload to the 6440 without the region code, the remote doesn't work, instead the TV button flashes slowly. You then have to press and hold the region code number on the remote until it's accepted and the remote works. I'd forgotten that and panicked!! I suspect that the reason for this is that if you connect your remote via the simpleset website, it will connect in the appropriate language. However, RMIR users won't need it to, and it's much easier to set it via RMIR.
2. Fixed.
3. The URC-6440 and OARUSB04G are the only remotes that use segments for which there are extenders, and so these with an extender are the only such remotes which support LKP and DKP special functions. I have been able to use this to give an error message if a user creates an LKP on the WatchTV or WatchMovie buttons. The message explains that an LKP on these buttons is not possible due to their dual use for Setup/Copy, so that users are not left baffled as to why this is an error.
URC7560/URC7562, URC8910, URC7980, URC6440/OARUSB04G and URC3661
davecs wrote:There are obviously subtleties in the RMIR file that stop certain entries being backwards-compatible with 2.14.18. Since that is our stable version, we need to get the official update out soon.
It is not possible to retain backward compatibility when making many improvements. So development versions may always create saved setups that will not load into the current stable version. I do, however, maintain forward compatibility so if anyone comes across a setup file that loads correctly in an older version of RMIR but not in the current version, that is a bug and I would like to know about it.
I will make this change in protocols.ini. In the post you reference, you also wrote
BTW, the learned signals in http://hifi-remote.com/forums/viewtopic ... 714#146714 decode as F12x, but apparently don't actually contain a different last command, so probably this decode is triggered by the short lead-out time. I suspect F12x will still work in this situation, and the fan will just ignore the last command byte of 0.
The lead-out in those learned signals is correct for F12x but not for F12, so it has to decode as F12x. Learned signals are notoriously bad at capturing end frames sent on key release, as the learning process has often completed before the key is released. So I am not convinced that these are not true F12x signals with an end frame.
I have replaced RMIR v2.15.7 in the RMIR Development folder with v2.15.8. This incorporates the various changes discussed above. (Apologies, Rob, your change just missed this build but will be in the next one).
As I have previously mentioned, the major addition in this version is a new tab that displays the user files of XSight Touch/Color remotes in a human-readable form. I have posted more about this, including a screenshot, here in the Nevo and XSight remotes thread.
mathdon wrote:I have replaced RMIR v2.15.7 in the RMIR Development folder with v2.15.8. This incorporates the various changes discussed above. (Apologies, Rob, your change just missed this build but will be in the next one).
As I have previously mentioned, the major addition in this version is a new tab that displays the user files of XSight Touch/Color remotes in a human-readable form. I have posted more about this, including a screenshot, here in the Nevo and XSight remotes thread.
All looking good on URC-6440. URC-3661 still OK with no bugs creeping in!
P.S. Earlier in this thread we mentioned a User Manual for the 3660 family. I've put one in the Wiki, here:
Rob, can you give me a link to a KM file that needs this change? As far as I can see, you have just added an Old Name that is exactly the same as the present name. OldNames will get looked at only if the present name fails, so it seems to make no sense to need an Old Name that is the same as the present one.
I was replacing all the KM files that I encountered with RM files, so the original is not there any more, but I still have some of the old KM files on my computer so I just re-loaded one here:
I know it doesn't look like it makes sense, but adding that entry does fix the issue. It's probably because the KM versions were home made protocols, whereas the RM entry is an official UEI protocol, so it has a different PID.
Also, there was one old KM file that used the "NEC2 Combo" and we don't have an equivalent for that in RM, so I converted it to NEC1 Combo.
Thanks for the files, Rob. You are right that you needed to add the current name as an old name because of the different PID. For some unknown reason, if there is no matching PID when loading a KM file, RMIR was searching only Old Names. Rather than add the name, as you have suggested, I have fixed the issue in RMIR so that it includes the current name as well when searching for Old Names. This will be in the next build.
I'm not sure if you want me to do anything about the NEC2 Combo file. I have checked that it doesn't load but presume that since you have created an equivalent RM file using NEC1 Combo, you are happy to leave it at that.
Onkyo receivers actually use a mix of NEC1 and NEC2, where most buttons use NEC1 and just some repeating type of buttons (VOL +/-, etc) use NEC2, so switching to NEC1 was more correct than using NEC2. And that was the only file using the NEC2 Combo, so now that I've changed it, it is no longer used.
I guess I was just curious why we added support in RM for the NEC1 Combo but not the NEC2 Combo, as I imagine there could be cases where folks might need it, and it did exist in KM. I guess I'm also surprised that the UEI combo don't let you switch it to NEC2.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
The Robman wrote:I guess I was just curious why we added support in RM for the NEC1 Combo but not the NEC2 Combo, as I imagine there could be cases where folks might need it, and it did exist in KM. I guess I'm also surprised that the UEI combo don't let you switch it to NEC2.
Probably because there is also [NEC 1or2 Combo] with PID=01 7E which incorporates both. Had you noticed this? Would that have suited your purpose?
Yeah, it probably would have worked perfectly. The task that I was doing was to collect all the Onkyo upgrades for the purpose of creating a master file (see this thread), and as I was opening the files using RM anyway, I decided to convert all the KM files into RM files to make things easier for the next person, so I just created the RM file in the same manner than the OP had created the KM file, I didn't do much re-configuring as I was handling about 50 files.
Rob www.hifi-remote.com Please don't PM me with remote questions, post them in the forums so all the experts can help!
