on Build 18 and, if I recall, some/all previous ones:
(1) Would it be possible for RMIR to tell me that the reason SAVE doesn't work, loops forever, is because the .rmir was Read Only (which I've made so a month ago)?
(2) Something is wrong and I don't know what it is.
About a month ago I successfuly uploaded a file for Atlas OCAP 1056 under the common extender 3.02. All sorts of tests and edits went through just fine.
Today I wanted to upload with an extra keymove and an extra macro and RMIR is complaining that the signatures don't match.
I downloaded the current contents, and the sigs are identical. And on all these files in RawData, Signature says "Copy" rather than 3X333X33. I don't think it did that before.

Edit few hours later:
6131 extended and Atlas under 2.11 extension can upload through build 18 and show correct signature on RawData tab.
For Atlas 3.02 extended I went back to build 15 or 16 and 17. They, too fail upload. I'll have to go back to build 12 which was last before my successful uploads Feb.26. Will report if I really do it.
I wonder what I've messed up or what changed here, if anything relevant.
That's how it looks
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13276_________________Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

Liz, I'll look into (1) but no promises. It depends whether or not Java can test whether or not a file is read-only.

On (2), I've looked into the code to see how this might be caused, and come up with only one possibility. I have tested that possibility and been able to reproduce this behaviour. So I think that in some testing of yours, you have created a copy of the RDF file named

If both RDFs are present in your RDF folder then it will cause this behaviour.

Edit: I have looked into (1) and found it easy, so next build will tell you if file is read-only. But in testing it, I found a peculiarity about extender v3.02 for the OCAP URC-1056. There is a Settings entry for LongPress with the values "BL Toggle" and "Deactivate". If you set it to Deactivate, then whenever you load the .rmir file, you get a message saying that the Fixed Data doesn't match, do you want to replace it with the values in the RDF? If you say Yes and save it, you get it again the next time you open it. Changing the setting to "BL Toggle" is the only way to stop this message.

This happens as both Fixed Data and this setting change the same data byte, but Fixed Data does it first and the setting overwrites any change it makes. You can get round this by replacing the first line in the [Fixed Data] section of the RDF, currently

Code:

$0014=$01,$00,$01,$FF,$00,$00,$00,$0F,$0F

by the two lines

Code:

$0014=$01
$0016=$01,$FF,$00,$00,$00,$0F,$0F

so it doesn't include the byte concerned. Should we make that change in the official RDF? Are other extender RDFs similarly affected?_________________Graham

Funny Sig issue:
Brilliant Thank you!
Sloppy of me for not changing .rdf to .txt or just adding .txt.
How on earth did you figure this one out? And how come RMIR didn't see the normal file
3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
and instead picked
Copy of 3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
I suppose Copy (2) of ... would've resulted in the same funny signature?

Does RMIR remember few things about what it was working with? The reason I ask, is that what became "Copy" was likely the file I used in the first place to make the original .rmir. I see nothing in the .properties regarding RDFs.

ReadOnly files - Thank you, it'll be useful.

Deactivate on LKP Setup:
Several recent posts indicate some people use it on Atlas, so making a change is probably desireable.

I don't like that setting since it's a slightly dangerous one and it's all too easy to do long press instead of short. I make a keymove on a pressable shift key instead. With no PIP on TVs, I use shift-pip-ch- to deactivate. Before Bill added it to the other settings, his extender had a deactivate button# and a keymove already coded. Now it doesn't. I just took a quick look through 3.02 rdfs looking for "deactivate", and so far only see it in Atlas OCAP 3X33, and RS 3X60 files and they're with different keys or settings. Hmmm, I thought these 3.02extenders were identical._________________Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

How on earth did you figure this one out? And how come RMIR didn't see the normal file
3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
and instead picked
Copy of 3X333X33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V3.02).rdf
I suppose Copy (2) of ... would've resulted in the same funny signature?

I figured it out by looking at the code to see how a signature of "Copy" could possibly be displayed, and the only way is from an RDF with a signature of "Copy" in the name.

When RMIR reads the filenames in the RDF folder, the signature is the part of the name up to the first space, and the name of the remote is what is in the first set of round brackets (with some special treatment of underscores). It builds two cross-reference maps from this data. One maps signatures to remote names, and this supports multiple names for the same signature as this actually occurs. The other maps remote names to signatures and allows only one signature per name, as again this reflects reality. So when it came across your Copy entry with a name it had already come across, it overwrote the original signature with the new one, "Copy".

When RMIR downloads a remote or reads a .ir file, it finds the signature and looks up the remote's name from the first map. When it reads a .rmir file, it gets the remote's name from that file as that is unambiguous, and looks up the signature in the second map. So it found "Copy".

Curiously, Copy (2) of ... would have been OK, as that would be read as a remote with signature "Copy" and name "2" ._________________Graham

Thomas made me reread things, so here is the history relevant to those fixed bytes (4 posts back):
From AtlasOCAP 2.13 ReadMe

Quote:

Activation of this extender is very different than previous JP1 extenders. Once activated, this extender will remain active until it is deactivated by the user. (activation will survive removal of the batteries, resets, etc) Two keymoves are provided in the default IR and HEX configurations to activate and deactivate the extender.

and

Quote:

This extender has two methods for deactivation.
First, a keymove is included with the extender that is bound to a key "Deactivate" that will deactivate the extender. Move this keymove to a physical key and upload this configuration to your remote and use that key to deactivate.

Second, the extender can also be deactivated using a long-press of the "setup" key on the remote. There is a setting in the IR settings panel that determines if a long-press of setup will deactivate the extender or will allow the user to set the clock. To enable deactivation ensure that "Deactivate" is selected, upload to the remote and press-hold the setup button (or whichever button you have defined as the shift key)

set the clock??

From 3.02, the newest, common, extender ReadMe:

Quote:

On most of the JP1.3 remotes a long press of the setup button will deactivate the extender. However, on the Atlas OCAP/1056 remote and the Radio Shack 15-100 the long press of setup will allow you to set other options in the remote.See the general screen in IR or RMIR for more information on what functions can be enabled with a long press of setup.

Liz,
Now, I have had to reread the readme --- the following only applies to the two remotes that I have which are in the v302 extender group, RS15-100 (clock) and RCRP05B.
The LKP of setup works without any key assignment. Device 1 80 is in the device list, but I don't know whether assigning a key to that device disables the default setup LKP. Being somewhat lazy, I have not bothered with it nor walked through the code.
IIRC, in RMIR, changing the setting for RS15-100 did not enable a clock-setting mode; you could choose to have the clock automatically set/reset whenever you uploaded to the remote. On RCRP05B the clock issue is moot.

In any case, I do know that your FIRST LKP deactivates the extender, and you must LKP the setup key a SECOND time to make it enter the options/configuration mode. The options are only available when the extender is deactivated._________________Tom Carlson

I asked above whether we should edit the RDF for the Atlas OCAP URC-1056, and possibly others, to remove the conflict between the fixed bytes and the LongPress setting. As I don't have this remote, or any related one, I can't really follow the discussion that it has provoked. But since it has caused discussion, it seems safer not to mess with this in the RDFs so I will make no change._________________Graham

Graham,
Sorry for derailing things
I just went through the exercise you started. Got the alert, changed RDF. I went back and forth between changing the LKP setting, saving, opening, uploading with either backlight or deactivation and your proposed fix is solid.

Default Atlas extender 3.02 initially sets LKP=Backlight ($0) at $615. So the only people who will be annoyed by the fixed data mismatch are those who change it to Deactivate ($80) and try to reopen their new .rmir file.

Your call, but I vote to change the RDF for Atlas 3X33 file, and plan to use mine edited your way, in case I chose to set LKP=Deactivate in the future.

Bill mentioned someplace that he might be adding more options. I won't be surprised if he stuffs few more into $15. That really will require preservation of that byte in Atlas. And see my quote about ext.3.02 for RS and Atlas, above, regarding options._________________Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

Your call, but I vote to change the RDF for Atlas 3X33 file, and plan to use mine edited your way, in case I chose to set LKP=Deactivate in the future.

When I looked into doing this, I realised that the situation is more complicated than it first seemed. The fixed data sets all the bits of the byte, in this case the byte at address $615, but the setting only affects the top bit. I don't know if the other bits in the fixed data value are relevant, as in this case they are all 0, but in another of the Common Extender RDFs there is a fixed data byte with value $0C in which only the top bit is changed by a setting.

To handle this, I have changed RMIR so that if the same byte is set by Fixed Data and a Setting then the Fixed Data only applies to the bits that are not set by the setting. This is not a trivial change, so there will be a new Alpha version for it to be tested. I am hoping, however, to move to a final release of v2.03 very soon._________________Graham

To handle this, I have changed RMIR so that if the same byte is set by Fixed Data and a Setting then the Fixed Data only applies to the bits that are not set by the setting. This is not a trivial change, so there will be a new Alpha version for it to be tested. I am hoping, however, to move to a final release of v2.03 very soon.

Yes. I see that also. And for a similar reason, I think, I mentioned that more options might go into such byte. I didn't think there might be a need to not preserve certain bits. Nothing is simple in this world

Graham,
Would it be possible to ignore certain protocol conflicts?
On 6131 I have a case of an existing device (Sangean tuner) using Aiwa protocol 005E hacked by Rob, but I retained its PID (used paste into .rmir file after RMIR objected to it). Works fine.
Now I want to add an Aiwa device which normally uses a standard Aiwa protocol.
I can find no way in RMIR to add this device without messing with changing PIDs and parameters.

But IR allowed me to add it long ago, and still does.

I know that the second device will be, and as far as I know does, use the hacked protocol, and causes no issues whatsoever.
Both devices show up as "00 5E*" on the Devices sheet.
I'd love RMIR to allow us to do some illegal things with a warning that it might not be the wisest thing to do._________________Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

Liz, I don't understand what it is that you cannot do. Can you please post the .rmir file to which you want to add the new device, and the .rmdu file of the new device, and tell me what you cannot do?_________________Graham

I just made .rmdu file for you since I was using a KM file before. Makes no difference. Same problem: Aiwa device cannot be added.
IRscope says that AiwaRadio used the same protocol as the Sangean box, which is what I figured will happen when I added the file by IR.
RDF I use is PVR0PVx1 ... 2K).rdf, common for old and new 6131 except few button locations.

Graham, I know both of these devices are against PID rules. But since it works in IR on XP and for my gear, would be nice if RMIR would issue a waiver (e.g. Are you really, really sure you want to do this?)._________________Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride