IR, KM, RM enhancement request

[johnsfine]

In the clipboard format for device and protocol upgrades is there a safe place to squeeze in the variant name? Preferably in a way that wouldn't break if you mix a version of IR, RM or KM that knows about it with one that doesn't?

Once that's done, I'd ask for some feature in IR to make some real use of it. But it's probably better to get it into the clipboard format first and deal with real use later.

Second, of course, IR needs some place to store it.

Actually, I'd prefer automatic renaming of protocol ID's in IR.EXE instead of the weaker form a ID collision management we sort of have in RM and KM, and storing the variant name in the .ir file is the critical step needed to make that even requestable. But since that request may be a bit much even then, variant names stored in the .ir file would let IR catch and report some configuration errors.

[e34m5]

By variants do you mean remotes like the 9960 that come in couple of flavors??

Oops I see now you were referring to protocols and upgrades rather than remotes themselves.

Perhaps we could use a dot notation. Something like VCR1800.0, .1, etc

[johnsfine]

Perhaps we could use a dot notation. Something like VCR1800.0, .1, etc

We use : in the RDF file, so if there weren't transition issues, I'd have suggested using : to directly modify the protocol ID. Note it is the protocol ID, not the setup code (as your example seems to imply) that is modified by variant. So the cleanest for protocol upgrade might be

Upgrade protocol 0 = 00 4b : 7 (S3C80) Thomson
76 76 11 8b 0e c5 41 05 07 00 f2 03 dc 00 f2 08
be 9c 40 31 02 27 07 03 31 c2 8d 01 33
End

but if you followed that for device upgrade, nothing is clean. Consider:

Upgrade code 0 = 00 00 (Cable/0000)
4b:7 00 01 f0
End

Anyway, the conceptual cleanliness (even if the above achieved that) should be secondary to avoiding transition problems, so I expect you'll reject both of the above.

[e34m5]

Hmm...good point. Which request is more desired at this time. Let's concentrate on one first if that's ok with you.

[johnsfine]

Which request is more desired at this time.

I assume you mean this one vs. Elizabeth's request (which I sort of hijacked)
https://www.hifi-remote.com/forums/viewt ... ght=#p17591

This one was intended as a longer term idea and also is something in which I have less of a feeling of knowing the answer. If someone suggests a decent compatible way to squeeze it in (a way that RM or KM could safely impliment before IR does) then it is an RM and KM request and doesn't become an IR request until later.

Otherwise, it's just something to keep in mind as you make related changes (if you change/increase what a .ir file stores regarding an upgrade for some other reason, you may want leave room for ptotocol variant).

As for the temporary removal feature, I think that would nice. But I was more interested in the connection between the basic changes I thought it would need and the basic changes other wish list items would need, than in the temporary removal feature itself.

As for the question of relative priority, the decision belongs to you, because you have to do the work. Toward that decision, I don't really have more to say myself. Maybe others do.

[gfb107]

Another thing to consider is that at this time RM and KM don't generally use the same variant names, so that adds another level of complexity to the issue.

[Mark Pierson]

Variant names can be specified as part of the "notes" line without affecting anything else at this time. To encode a variant name so that it is useable in the future will likely need more thought (and code changes) on the IR side.

As variant name discrepancies, I can probably add them to KM based on the current details in protocols.ini without too much trouble.