 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
 Posted: Tue Jun 08, 2010 10:20 am Post subject: |
 |
|
| 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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
 |
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Tue Jun 08, 2010 10:33 am Post subject: |
|
|
| 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.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Tue Jun 08, 2010 10:58 am Post subject: |
|
|
| 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.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Tue Jun 08, 2010 11:07 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Tue Jun 08, 2010 11:19 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Tue Jun 08, 2010 11:20 am Post subject: |
|
|
| 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:
http://www.hifi-remote.com/forums/viewtopic.php?t=6741&start=180&sid=542788cb70a52e9fa88f3390ef0fd1a3
I must admit I did not understand the integration when I first loaded RM-IR either, but they are fully integrated.
xnappo |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Wed Jun 09, 2010 9:31 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Thu Jun 10, 2010 7:06 am Post subject: |
|
|
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
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu Jun 10, 2010 7:52 am Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu Jun 10, 2010 9:08 am Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Thu Jun 10, 2010 9:26 am Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu Jun 10, 2010 9:53 am Post subject: |
|
|
| 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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Thu Jun 10, 2010 10:11 am Post subject: |
|
|
| 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?
| Quote: |
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.
| Quote: |
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 |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Thu Jun 10, 2010 11:59 am Post subject: |
|
|
| 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
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
