DevParms= in protocols.ini

Post by **The Robman** » Wed Jul 15, 2020 4:09 pm

Do we have any sort of "old device" type concept for protocols.ini ?

I'm noticing that the various protocol entries alternate between DevParms=Device and DevParms=Device Code, the net result being that if you switch protocols you could lose your device code. This is currently the case if you switch between NEC1 and NEC1 (no repeats).

I'd like to go through protocols.ini and sync everything up, but I'm afraid that if I did that, I'd mess up any RMDU files that use the old wording.

Post by **mathdon** » Thu Jul 16, 2020 3:29 am

The Robman wrote:I'd like to go through protocols.ini and sync everything up

Please don't. It would cause more problems than it would save.

Post by **The Robman** » Thu Jul 16, 2020 7:33 am

I know, because it would break existing RMDU files, but that's why I was asking if there's an "old device code" concept, like there is for protocols. It's quite annoying when you change from one version of a protocol to another to lose your entries.

Post by **mathdon** » Thu Jul 16, 2020 11:13 am

The Robman wrote:that's why I was asking if there's an "old device code" concept

No, there isn't. Protocols.ini was not well constructed. It is not just "Device" versus "Device Code", there is also "Device Hi", "Device Lo", "Device1" and others, not to mention "Subdevice" versus "Sub device", "Sub-device", "SubDevice1" and "OBC" versus "OBC1" and more.

There is no simple solution. I have created uei-executor entries in IrpProtocols.xml to handle all this when importing and exporting device upgrades but as far as RMIR itself is concerned, I think we just have to live with the imperfect situation that history has left us with.

Post by **The Robman** » Thu Jul 16, 2020 11:22 am

Yeah, I know about the other variants, I limited it to one to simplify the question.

If we're not open to revising the protocols.ini entries, can we look for other options to avoid having RM keep dropping data when you switch from one version of a protocol to another?

This is an age-old problem that dates back to the original switch from KM to RM, because KM would never drop the data.

One possibility might be to link the different variants in protocols.ini but I think a simpler possibility might be to simply say... when you switch from one protocol to another, the data in the first box in RM will still be in the first box after the switch, even if the name of the box changed from "Device Code" to "Device". Ditto for the 2nd box, etc.

Post by **The Robman** » Thu Jul 16, 2020 3:52 pm

I just tried an experiment. I created a dummy upgrade and saved it. Then I changed protocols.ini from DevParms=Device to DevParms=Device Code and re-opened the file and it worked, so I checked the file, it turns out we don't save the words "Device" or "Device Code" in the file, we just say "ProtocolParms=12 34 15 0"

Which leads me to the conclusion that if we were to change some of these entries in protocols.ini it wouldn't actually cause any problems.

Post by **The Robman** » Thu Jul 16, 2020 5:28 pm

With that last discovery, I went ahead and updated my copy of protocols.ini so that the DevParms labels are as in sync as possible, and I've tested it and it's working great.

I just did this for me, but if anyone else wants to try it, I've loaded a copy in the Diagnosis Area:
https://www.hifi-remote.com/forums/dload ... e_id=26014

Post by **mathdon** » Fri Jul 17, 2020 5:43 am

The Robman wrote:Which leads me to the conclusion that if we were to change some of these entries in protocols.ini it wouldn't actually cause any problems.

After I said don't do it, it occurred to me that the names might not be used in .rmdu files. I have checked, and I agree with you that it doesn't cause problems to change them, but I don't like doing so in case there are reasons, such as names taken from official protocol specs, why they are as they are and also it may cause confusion to some users familiar with the old names. So I have created an alternative solution to this issue for the next build. This is simply to improve the matching of names when changing protocol. So spaces, hyphens, underscores and case will be ignored and "Device Code", "Main Device" and "Device Number" will all be treated as "Device".

This covers most of your changes, and some extra ones too, such as matching Subdevice with Sub-device and Sub Device. On the whole, the ones this does not cover are ones I do not agree with. If a protocol has Device 1, Device 2, Device 3 I think it is confusing to change Device 1 simply to Device. The issue only affects device parameters that are set once per protocol, not separately for each function, so it is not a big issue to have to re-enter them manually. When changing from a simple to a combo protocol, or vice versa, it seems to me preferable to have to put in some thought rather than rely on an imperfect algorithm. So I hope you think what I have done is a reasonable compromise.

Post by **The Robman** » Sun Jul 19, 2020 4:22 pm

If we agree that "Device", "Device Code", "Main Device" and "Device Number" are all the same, let's agree to clean up protocols.ini for those.

If we disagree on "Device" vs. "Device 1" and "SubDevice" vs. "SubDevice 1", let's use your new logic to link those instead. I can give you an easy scenario where it would help, can you think of one where it would hurt?

The scenario is, someone has a device where all the buttons in their upgrade use the same device and subdevice codes, but then they discover that there are additional functions that use a different sub-device code, so they want to switch from using NEC1 to one of the combo versions. I think it's a safe assumption that they will want to continue using the existing device and sub-device codes for the existing functions and then add new device and/or sub-device codes for the new functions. Doing it your way, the user would have to take a screen shot first, or write down the codes first because RM will blank them out when they select the combo version of the protocol. I know I've been bit by this many times when I've tried changing the selected protocol.

Now that I think about it, I've also lost all of the button codes at times, so I think I need to do the same review on the labels used for button codes.

Post by **mathdon** » Mon Jul 20, 2020 5:46 am

The Robman wrote:If we agree that "Device", "Device Code", "Main Device" and "Device Number" are all the same, let's agree to clean up protocols.ini for those.

I don't know if they are all the same. There may be reasons for use of the different forms. The creators of those entries must have used them for some reason, and I do not want to second-guess them. What I have agreed to is to treat them as equivalent when changing protocols, without changing protocols.ini itself. That is what my algorithm does.

I think it's a safe assumption that they will want to continue using the existing device and sub-device codes for the existing functions and then add new device and/or sub-device codes for the new functions. Doing it your way, the user would have to take a screen shot first, or write down the codes first because RM will blank them out when they select the combo version of the protocol.

Device and Subdevice codes, that is two numbers that would need to be remembered or written down and re-entered for the new executor that, by its very nature, has a different set of device parameters. I do not think that is excessive, and I believe that the change from a simple to a combo executor should require some conscious thought due to the additional device parameters that are involved.

can you think of one where it would hurt?

Yes. You want to change between a simple and a combo executor without any conscious thought involved. So a user has a combo executor with more than one device code but decides to change to a simple executor because it looks simpler, has shorter executor code or for any other reason. With your way, it works seamlessly. The functions with the second device code are still there, but no longer work as they are now assigned to the first device code. No thought involved, but a corrupted result.

Post by **The Robman** » Mon Jul 20, 2020 7:23 am

I was probably the author of some of the protocol entries with inconsistent device code labels, so in my case it wasn't done on purpose.

I think I would qualify as one of the primary users of RM and I always use conscious thought when creating or modifying an upgrade, and I have been bit countless times by what I consider to be the RM bug where it clears out stuff that I have entered. Fortunately for me, editing protocols.ini fixes this and it's something I should have done years ago. The small task for me to keep my version in sync with any newer versions is worth it for the payback of not losing your code entries.

Post by **mathdon** » Mon Jul 20, 2020 10:25 am

The Robman wrote:I think I would qualify as one of the primary users of RM

Indeed, I am aware that although this discussion is being phrased in terms of users generally, it almost certainly affects only you. If you want me to put in an option to extend my new matching algorithm so that it ignores a final 1 at the end of a device parameter name, I will do it. It will join other options and features that I have added at your request that are primarily for your benefit, like the import of ict files as learned signals. But for the reasons I have expressed, I do not want to make wholesale changes to the parameter names in protocols.ini.

Post by **mathdon** » Tue Jul 21, 2020 8:42 am

mathdon wrote:If you want me to put in an option to extend my new matching algorithm so that it ignores a final 1 at the end of a device parameter name, I will do it.

I have included this in build 6, just released. Menu item Options > Advanced > Ignore final 1 on dev parm names. I think this should meet, for matching purposes, everything that you included in your name changes in protocols.ini.

Post by **The Robman** » Tue Jul 21, 2020 8:54 am

I assume that defaults to OFF then? Sorry to say, but I don't think that will help most folks because most people don't know about the advanced options, so when they switch from a simple protocol to a combo protocol and lose all of their device codes, they'll just look them up and re-enter them without knowing that it could have been avoided.

Furthermore, I just took a look and, even though this is only relevant to RM, I see the advanced setting is in RMIR, which makes it even harder to find.

Post by **mathdon** » Tue Jul 21, 2020 9:42 am

It does not only affect RM. The Device Editor of RMIR is essentially RM so it affects that too. It is an advanced option in RMIR but it is also in the Options menu of RM without any mention of Advanced.