JP1 Remotes

vickyg2003 wrote:Call me dense here, but I don't understand why all of our homemade protocols need to be included in protocols INI, since manual settings can be included in the rdmu or km text file.

Once a protocol gets added to DecodeIR it's a good idea to also add it to protocols.ini because when the next user comes along with a device that uses the same protocol (ie, the one that we just created a homemade executor for) they will be able to create an upgrade using RM.

Graham, if you want to keep the process simple, how about this. When someone adds a new executor with the same PID as either an existing protocol upgrade or a built-in executor (from the list in the RDF) IR could pop up a warning informing the user of the conflict and stating whether the conflict is with an upgrade or a resident executor. The warning should give them the option of overlaying the existing upgrade or changing the PID to a new one. They would then have to manually change the PID on the device upgrade (if the combo format is not adopted), so IR should give them an easy way to do that also.

The Robman wrote:

vickyg2003 wrote:Call me dense here, but I don't understand why all of our homemade protocols need to be included in protocols INI, since manual settings can be included in the rdmu or km text file.

Once a protocol gets added to DecodeIR it's a good idea to also add it to protocols.ini because when the next user comes along with a device that uses the same protocol (ie, the one that we just created a homemade executor for) they will be able to create an upgrade using RM.

Definately dense. Thanks for the explanation. My process is a little off here.

The Robman wrote:

gfb107 wrote:RMIR already considers the protocol upgrade to be part of the device upgrade that uses it.

How? What does RM do to link them together? Could RMIR handle the homemade executors in the way being discussed?

RMIR has always treaded the protocol upgrade as part of the device upgrade. That's why the Protocol Upgrade tab in RMIR is basically useless, and why we have discussed removing it altogether.

It would take relatively minor changes to RMIR to handle homemade executors they way being discussed here.

The Robman wrote:Just keep in mind that, the more you require the end user to think for themselves, the more difficult you make it for newbies to use JP1. Things that are really simple for us experts are not so simple for people that only use JP1 once every 2 or 3 years when they get a new piece of equipment.

I agree, and in RM-IR it is possible to handle it all behind the scenes.

xnappo

gfb107 wrote:We should, as a community, embrace RMIR as the future of JP1, and resist the temptation to enhance IR and KM to deal with these growing issues. They've been great tools that have been the foundation of the JP1 world, but the fact that they are separate tools will forever limit how far they can go.

Greg, I may be missing the obvious, but I have never understood in what sense RM and RMIR are integrated, other than that they are both opened from the same program. If you start up RMIR, it looks rather like IR.exe and seems to have no more connection to RM than does IR.exe. Even less, possibly, since IR.exe has a button for opening RM but I haven't found a way of opening RM from RMIR (or vice versa). What am I missing?
________________
Graham

mathdon wrote:

gfb107 wrote:We should, as a community, embrace RMIR as the future of JP1, and resist the temptation to enhance IR and KM to deal with these growing issues. They've been great tools that have been the foundation of the JP1 world, but the fact that they are separate tools will forever limit how far they can go.

Greg, I may be missing the obvious, but I have never understood in what sense RM and RMIR are integrated, other than that they are both opened from the same program. If you start up RMIR, it looks rather like IR.exe and seems to have no more connection to RM than does IR.exe. Even less, possibly, since IR.exe has a button for opening RM but I haven't found a way of opening RM from RMIR (or vice versa). What am I missing?
________________
Graham

See my post here:
https://www.hifi-remote.com/forums/viewt ... 90ef0fd1a3

I must admit I did not understand the integration when I first loaded RM-IR either, but they are fully integrated.

xnappo

So, now that we had our nice little side-jaunt to the RM-IR thread, I am brought back here as Capn Trips brought up the outdated Atlas 1056 RDF, which got me looking at it and reminding me of the 'protocol 42' issue.

My original problem here was that my upgrade specifies 0042 as 'Panasonic Multi-device hacked'. But the Atlas has another protocol 0042 built in which is something totally different.

Somehow though, now when I load this .rmdu(created for an RS1994), RM-IR is automatically changing it to 01E1.

Does this mean RM-IR already has some sort of conflict resolution capability? Or is it just that this has been fixed in protocols.ini and RM trusts the protocol name over the ID?

xnappo

That's because I changed the PID for Panasonic Multi-Device (Hacked) to 01 E1.

RMIR does have a way of dealing with PID conflicts, as discussed here.

I don't remember why I decided to change the PID instead of adding an AlternatePID. Maybe it was that it solved this particular instance of the problem without having to update the RDFs of all the remotes that have 00 42 built in.

But that also causes other problems: RMIR won't be able to identify PID 0042 when importing IR files (or downloading from the remote).

Guess we need to coordinate an update to the RDFs with a correction to protocols.ini so I can restore the PID to 00 42 and add the AlternatePID=01 E1

Part of what I'm doing with my effort of catalog all of the JP1 upgrades is to make a note of all upgrades that use Manual Settings with a PID other than $001FF, then when I'm done, I'm going to go back and take a closer look at all of them. If it turns out that it's a homemade executor, I will reformat it to use $01FF. If I find upgrades that are using homemade combo protocols, where there is now an official combo, I'll switch them. So, my goal is to get all the misused PIDs out of the system.

I'm also going to campaign very strongly to get them all out of protocols.ini too, and if there are cases where the RDFs have been altered to allow for misused PIDs, I'd like to see those updated too.

So Panasonic Multi-Device (Hacked) should have PID=01 FF, once you are done?

Does this also pre-suppose a change to RMIR/IR to dynamically reassign PIDs of $01FF to an available PID when a conflict is detected?

I would first research what the "Panasonic Multi-Device (Hacked)" really does and if I determine that there's a genuine UEI executor that does the same thing (that might not have been available when the upgrade was created, or maybe we just didn't know about it), then I would re-format the upgrade to use the UEI executor.

While it would be nice if the tools had functionality to handle the homemade executors, that's not a pre-requisite to me using $01FF for all the executors that I create by hand (which I've been doing for ages anyway).

I would really like to get the PID clashes that are in protocols.ini out of there though, especially the Tivo vs. Acer Keyboard clash.

The Robman wrote:I would first research what the "Panasonic Multi-Device (Hacked)" really does and if I determine that there's a genuine UEI executor that does the same thing (that might not have been available when the upgrade was created, or maybe we just didn't know about it), then I would re-format the upgrade to use the UEI executor.

But that will potentially break the upgrade for older remotes won't it? The newer remotes that potentially have replacement protocols have plenty of memory usually - so I think maintaining backward compatibility is more important than using UEI protocols when they develop one. Now if there is a protocol that has been there since the 1994, that we just didn't understand, then I agree - but I think that will be a rare case.

The Robman wrote: While it would be nice if the tools had functionality to handle the homemade executors, that's not a pre-requisite to me using $01FF for all the executors that I create by hand (which I've been doing for ages anyway).

Err, 4/8 of my devices in my house use a custom executor. That would be really confusing to a new user, especially with RM-IR. If we change them to all be $01FF, then we really need to have RM-IR auto-assign.

xnappo

xnappo wrote:But that will potentially break the upgrade for older remotes won't it? The newer remotes that potentially have replacement protocols have plenty of memory usually - so I think maintaining backward compatibility is more important than using UEI protocols when they develop one. Now if there is a protocol that has been there since the 1994, that we just didn't understand, then I agree - but I think that will be a rare case.

No, the user with an old remote doesn't care whether he's loading a protocol called $0042 (the misused hacked name that we might have called it) or $0123 (the real UEI name). It's a protocol upgrade either way, so what's the difference. Now, for people with newer remotes that happen to have the official protocol factory installed, it will save them a protocol upgrade.

When we create better executors that UEI (like ours might use 1 variable byte and theirs use 2, for example) we try to re-use the official PID and use versioning.

The Robman wrote: While it would be nice if the tools had functionality to handle the homemade executors, that's not a pre-requisite to me using $01FF for all the executors that I create by hand (which I've been doing for ages anyway).

xnappo wrote:Err, 4/8 of my devices in my house use a custom executor. That would be really confusing to a new user, especially with RM-IR. If we change them to all be $01FF, then we really need to have RM-IR auto-assign.

I would argue that you're not a typical user, and I would also guess that you are knowledgeable enough to know how to change the PIDs. The typical "new user" is not likely to need custom protocols for 4 out of 8 of their devices. To demonstrate my point, I've been using the $01FF PID for protocols that I create for several years, and I think I am the primary writer of homemade executors, and I don't think I've seen even one complaint from anyone who's trying to load two of them into their remote.

Of course, I'm not arguing against having the tools be modified to handle the $01FF PIDs, but I'm not going to start re-using UEI PIDs for my homemade executors while I wait for the tools.

The Robman wrote: No, the user with an old remote doesn't care whether he's loading a protocol called $0042 (the misused hacked name that we might have called it) or $0123 (the real UEI name). It's a protocol upgrade either way, so what's the difference. Now, for people with newer remotes that happen to have the official protocol factory installed, it will save them a protocol upgrade.

When we create better executors that UEI (like ours might use 1 variable byte and theirs use 2, for example) we try to re-use the official PID and use versioning.

Right - that is what I am referring to - the case where the data is different because of how the executor works. How will we use versioning? How will a new user know whether they have the UEI protocol available before they download the upgrade?

I would argue that you're not a typical user, and I would also guess that you are knowledgeable enough to know how to change the PIDs.

Perhaps, but my components are not wacky, and the only way to control them is with these protocols.

Of course, I'm not arguing against having the tools be modified to handle the $01FF PIDs, but I'm not going to start re-using UEI PIDs for my homemade executors while I wait for the tools.

Definitely think it needs to be on the to-do list.

xnappo

xnappo wrote:Right - that is what I am referring to - the case where the data is different because of how the executor works. How will we use versioning? How will a new user know whether they have the UEI protocol available before they download the upgrade?

Take a look at how we handle the various versions of the $007E executor. In RM it has several names, including...

Pioneer DVD
Pioneer DVD2
Pioneer MIX
etc