JP1 Remotes

The Robman · Posted: Fri Jul 08, 2005 11:04 am Post subject: Suggestion for RM

I've noticed that when you open a KM upgrade using RM, you usually have to re-select the original remote, this is typically because the original upgrade might have been created for a "URC-881x/801x/601x" for example, whereas RM wants to know exactly which remote was used.

My problem with this is that most people won't know (or care) what the original remote was, as they are going to want to re-program the upgrade for their remote. Therefore, would it be possible to have RM pick a remote instead of the user? Using the example of the "URC-881x/801x/601x", RM should pick the URC-8811 (that's just my choice, any of the 3 would do), then if the user really wants the upgrade to be for a URC-6131 (for example) they would change the selected remote. Having them first select whether the original file was created for a URC-8811, URC-8011 or URC-6011 is an un-necessary (and possibly confusing) distraction.

If there are examples (like with the "Millenium 4, possibly) where there are several different versions with different keymaps, you'd need to know which RDF corresponds to the versions of the remote that are programmed into KM.

If the problem is that the remote names used in KM don't exactly match the names used for the RDF files, then it might be a good idea to have some sort of *.ini file which would be used to cross-reference the KM names to the RDF names.

Wha'dya think?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

The Robman · Posted: Fri Jul 15, 2005 4:30 pm Post subject:

Greg, or anyone else, any thoughts on this suggestion?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

DaleMac · Joined: 29 Apr 2005 Posts: 27 Location: Brisbane, Australia

I would have to agree with you there, Rob.
You usually intend to make changes anyway, so the original remote that the upgrade was for is probably not that important.
It's like the popup that tells you that you are going to have to change some button assignments when you change from one remote to another. It's a well written piece of software and helpful for a newbie, but I think that most users probably realise that they will have to go to the button or layout panel to reassign things the way they want anyway. An inexperienced user could just click the auto assign button.

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Rob, You asked for it, so here goes: Hard to tell. Probably a good idea, but what would you select as the prime choice?
In the case of 8910, for instance, I may want 8910 and the next person will want HTPro, all in the same bucket using the same RDF and we'll have a first ever jp1 war Razz

RM has a neat provision to remember your favorite remote(s), so I suppose this suggestion is for the very first use of RM after installation.

The Robman · Posted: Sun Jul 17, 2005 9:39 pm Post subject:

mtakahar · Expert Joined: 03 Aug 2003 Posts: 281

I think it's a great idea if you have only one single type of remote and you wouldn't create upgrade for someone else who has a different model, which may be the case for majority of newbies and even some regulars.

But not for me, please. I will lose some button assignments as soon as I open an upgrade for one remote if I was editing another upgrade for another remote. Just changing the remote model back won't put them back where they were unless they happened to be the same as as what auto-assign would put, but it's unlikely to be the case for those exotic buttons.

So, if someone is going to implement this behavior, please make sure it's configurable.

BTW, if people think this is good behavior out-of-the-box, then perhaps KM should do the same, too.

Hal

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

I'll take a look at implementing this. Let's just be clear on where I'm going with this.

If, when loading an upgrade, RM can't figure out exactly which remote is used by that upgrade, RM currently builds a list of what it considers similarly named remotes, and then prompts the user to pick one of those remotes.

What Rob is suggesting is that RM simply pick (the first) one of those similar remotes and use it without prompting the user. The reasoning behind this is that the user normally doesn't really care what remote was used by the original creator of the upgrade. The user is probably going to change the remote to what (s)he actually has anyway.

Note again that this only happens when RM can't figure out exactly which remote was used in the first place. This should only happen when importing a KM upgrade, not when loading an exisiting RM upgrade.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

johnsfine · Posted: Mon Jul 18, 2005 7:56 am Post subject:

I probably should have investigated a problem I've seen a few times and haven't reported before:

I open a KM upgrade in RM and get a choice of two RDFs.
If I pick the first one, RM crashes. If I pick the second RM works.

I think my RDF directory was a clean unzip of the current collection of RDF files, so the first choice offered shouldn't have been some old imcompatible file. I think the KM upgrades I was opening when this happened were for 8910's.

If RM automatically picked the first, this minor bug would be a major bug.

Second: I'm not too up_to_date on the transformation process RM goes through if the protocols.ini entry it would want to use isn't available for the model. I don't know when/how it decides to change to a compatible (with the remote) protocols.ini entry and I don't know how many situations there are in which data is lost in the upgrade by that sort of change (there used to be a bunch of problems in that area).

I'm worried that automating the first choice of remote may force two changes of protocol entry when they weren't actually needed.

Overall, I also find that initial question annoying and I never no the right answer (short of trying one, deciding something is wrong and then trying another) so I agree with Rob that I'd like it to go away. I'm just a bit worried about whether other things are robust enough to allow that to go away. I know Greg has improved RM a lot since the last time I did any systematic testing, so maybe I'm worrying over nothing.

The Robman · Posted: Mon Jul 18, 2005 10:37 am Post subject:

In most cases, the choice of remotes are all very similar (eg, URC-8910 vs. URC-9910 vs. HTPRO), so no button assignments will be lost, but I guess if the choice is between the URC-8811 and the URC-6012 and there are functions assigned to the macro buttons, you might lose a couple of assignments. So, with this in mind, maybe things could be set up so that there's a *.ini file where you can specify which remote to use, and when there's no entry in the *.ini file, RM will just pick the first one.

Greg is correct that this should only happen when people try to edit KM files using RM, the only other exception would be when the name of an RDF changes, which is not common.

Regarding John's point about the selection that causes RM to crash, that tends to imply that there's a faulty RDF out there, so we should probably look into that instance a little deeper.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

johnsfine · Posted: Mon Jul 18, 2005 11:40 am Post subject:

The Robman · Posted: Mon Jul 18, 2005 11:49 am Post subject:

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Nils_Ekberg · Posted: Tue Jul 19, 2005 9:33 am Post subject:

gfb107 · Expert Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC

We dont' have to worry about RM selecting the 601x instead of the 881x and this causing a loss of button assignments. In Rob's example we were worried about functions assigned to the macro buttons. The 6012 still has the macro buttons, it's just that they are phantom buttons. This isn't anything we have to worry about. This is the case for all remotes that share an RDF. One RDF means one set of buttons.

I'm a bit more worried about the extenders, because in this case buttons will disappear. The extender supports x-shifted buttons, and if an upgrade create d for a remote with extender is opened and RM picks a remote using the unextended RDF, any assignments to the x-shifted buttons will be lost. I'm going to have to work on improving RMs name matching code. Although, as I think some more, this isn't really a problem because the only extended remote KM supports is the URC-6131, and even then it doesn't support x-shifted keys.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

Nils_Ekberg · Posted: Tue Jul 19, 2005 10:07 am Post subject:

Greg, I didn't think KM let you use the extender version only the base remote RDF equivalent to create upgrades.
_________________
Nils
Files Section
Diagnosis File Section