How does RM list remotes?

[gfb107]

I did some testing with IR with different file names and it did not seem to cause any impact.

I didn't expect any functional problems, I'm just wondering if we want the two to be consistent. So far, IR and RM have been using the same names for the remotes, since they are taken from the RDF file names. This would introduce a difference between the two.

Once again, let me know when to upload the images and maps that went thru the weight loss program which by the way is all of them.

I suggest you just put them up whenever you have them. I'll download them and update CVS, and then whenever I do a build the new files will be there.

I guess you haven't had any luck getting your SSH client to work with SourceForge?

[jamesgammel]

I did some testing with IR with different file names and it did not seem to cause any impact.

I didn't expect any functional problems, I'm just wondering if we want the two to be consistent. So far, IR and RM have been using the same names for the remotes, since they are taken from the RDF file names. This would introduce a difference between the two.

Greg,

The RM rdf's are supposed to be RM/IR compliant. I've suggested to Mark Pauker that when he uploads a new version of IR that he simply copy and paste the whole batch from RM's rdf folder. Nils has been doing a good job of keeping rdf's up to date and modified as required, and currently the rdf's in the RM rdf folder are more accurate and up-to-date than the ones in IR, even the recently updated 3.21a. If Mark follows thru, then both RM and IR should be using identical rdfs, when he makes the next update. My personal copies of IR (3 or 4) all have had IR's rdf's deleted, and are using RM rdf's instead. No problems thus far with 6800, 2104, 1994 or both Mill4's.

If rdf names are going to be changed to some uniformity, it should be done before Mark updates IR so he can just grab the whole batch from RM.

Jim

[mr_d_p_gumby]

Is there a way to have the three remotes share an RDF while using different images?

While we're at it, let's not forget that button names can change betweeen models that otherwise could share the same RDF. Case in point: The RS 15-1918, 15-1919, 15-1925 can share one RDF, but the URC-7070, which is otherwise identical, cannot because nearly all the buttons are labelled differently.

Just a thought: If the multiple image map convention being discussed here could also cause the button names/availability to change (to match the image), then the number of RDFs could be reduced further.

[Nils_Ekberg]

I didn't expect any functional problems, I'm just wondering if we want the two to be consistent. So far, IR and RM have been using the same names for the remotes, since they are taken from the RDF file names. This would introduce a difference between the two.

Just like Jim G I don't use the RDF's from IR anymore either. I just put IR, KM and RM in the RM root directory with the RDF's from the RM distribution.

Once again, let me know when to upload the images and maps that went thru the weight loss program which by the way is all of them.

I suggest you just put them up whenever you have them. I'll download them and update CVS, and then whenever I do a build the new files will be there.

I am concerned about doing that since a couple of times when I had more than 1 set of updates we got out of synch. I would rather keep working on them and batch them when you are ready. But if it is better for you I will do it today.

I guess you haven't had any luck getting your SSH client to work with SourceForge?

No, and it is a proprietary SSH client which conflicts with any other I install. I need it for part of my old job but haven't completely turned over the function yet.

[Nils_Ekberg]

Is there a way to have the three remotes share an RDF while using different images?

While we're at it, let's not forget that button names can change betweeen models that otherwise could share the same RDF. Case in point: The RS 15-1918, 15-1919, 15-1925 can share one RDF, but the URC-7070, which is otherwise identical, cannot because nearly all the buttons are labelled differently.

Just a thought: If the multiple image map convention being discussed here could also cause the button names/availability to change (to match the image), then the number of RDFs could be reduced further.

The convention that Greg added to allow a generic button name and a display name can be used to address this problem. I will watch closely as we move forward with this.

[gfb107]

The RM rdf's are supposed to be RM/IR compliant.

Absolutely true. We've gone to great lengths to make sure of that.

What we're talking about here is making a change to the name of the RDF file (and an RM-specific field in the RDF), that will change what RM displays for a remote.

Specifically, if we have the RDF "6_806_80 (URC-[881x][801x][601x]).rdf", RM would present this single RDF as 3 different remotes: URC-881x, URC-801x, abd URC-601x. IR as it stands today, would only display one remote: URC-[881x][801x][601x]. This is the inconsistency I am talking about.

I've suggested to Mark Pauker that when he uploads a new version of IR that he simply copy and paste the whole batch from RM's rdf folder. Nils has been doing a good job of keeping rdf's up to date and modified as required, and currently the rdf's in the RM rdf folder are more accurate and up-to-date than the ones in IR, even the recently updated 3.21a. If Mark follows thru, then both RM and IR should be using identical rdfs, when he makes the next update. My personal copies of IR (3 or 4) all have had IR's rdf's deleted, and are using RM rdf's instead. No problems thus far with 6800, 2104, 1994 or both Mill4's.

Nils has been doing a fabulous job, and RM wouldn't be anywhere near where it is without his help. It is also true that there has been more active development of RM than IR, and therefore there have been more opportunites to release updated RDFs.

However, from a distribution point-of-view, it would actually make more sense to distribute the RDFs with IR instead or RM. This is simply because a higher percentage of users need IR than need both IR and RM.

Having a consistent set of names for the RDFs will be beneficial, but I'd like to see some effort put into adding generic names (and restrictions). This will have the following benefits:
1. Improve success when importing KM upgrades; the mapping of functions onto buttons won't get lost
2. Improve changing the remote in an existing upgrade; less button assignments will get lost.
3. RM and IR will correctly reflect how buttons are allowed to be used by the remotes.

[jamesgammel]

The RM rdf's are supposed to be RM/IR compliant.

Absolutely true. We've gone to great lengths to make sure of that.

What we're talking about here is making a change to the name of the RDF file (and an RM-specific field in the RDF), that will change what RM displays for a remote.

I'm aware of the current topic, but there are other things which feed in as well.

Specifically, if we have the RDF "6_806_80 (URC-[881x][801x][601x]).rdf", RM would present this single RDF as 3 different remotes: URC-881x, URC-801x, abd URC-601x. IR as it stands today, would only display one remote: URC-[881x][801x][601x]. This is the inconsistency I am talking about.

well, there's other closer similar inconsistencies as well. The 6800 and 7800 share an rdf. The 6800 thinks it's a 7 device remote, and will actually work 7 devices, however, it's not as simple as just assigning a setup code to the missing device button.

" It is also true that there has been more active development of RM than IR, and therefore there have been more opportunites to release updated RDFs. "

Only 2 people update IR on a consistent basis, Rob and Mark. I think John did one time to correct an error. IR 3.21a was just put together recently and put in the tools folder, and evertything in the rdf folder was deleted. That *should* have been a golden opportunity for the switchovers in rdf's from the old IR format, and just replaced them with a copy from one of the latest RM revisions.

"However, from a distribution point-of-view, it would actually make more sense to distribute the RDFs with IR instead or RM. This is simply because a higher percentage of users need IR than need both IR and RM."

Agreed, an opportunity to change the whole batch of rdf's from the old IR ones to the new RM ones was lost just recently.

"Having a consistent set of names for the RDFs will be beneficial, but I'd like to see some effort put into adding generic names (and restrictions). This will have the following benefits:
1. Improve success when importing KM upgrades; the mapping of functions onto buttons won't get lost
2. Improve changing the remote in an existing upgrade; less button assignments will get lost.
3. RM and IR will correctly reflect how buttons are allowed to be used by the remotes."

Agreed, I've seen #1 at work. I haven't had the need to do a #2 yet, but I'm sure I'll eventually have to.

Jim

[Nils_Ekberg]

Having a consistent set of names for the RDFs will be beneficial, but I'd like to see some effort put into adding generic names (and restrictions). This will have the following benefits:
1. Improve success when importing KM upgrades; the mapping of functions onto buttons won't get lost
2. Improve changing the remote in an existing upgrade; less button assignments will get lost.
3. RM and IR will correctly reflect how buttons are allowed to be used by the remotes.

I am a little confused on what list we are using from KM for the generic name function. I have actually been doing some updates to RDF's over the last couple of days based on what I thought was the generic list but having some inconsistencies. If I use the names from KM's default function sheet they don't all work and the names on KM's button sheet is remote specific so it does not seem logical that it is the list.

In a KM import example when using the TV/VCR name from the KM functions tab in the 15-2116 RDF like this tv/vcr:TV/Video{A/B}=$20 does not work. If I make it tv/video:TV/Video{A/B}=$20 it does.. tv/video is the 2116/2117 name on the button tab. I can put anything in two different RDF's for the tv/vcr button and it converts between remotes perfectly. In other words it does not care what it is as long as it is the same in the 2 RDF's

So which list am I suppossed to use (KM Function, KM Button/KeyMap or another list) OR what am I doing wrong?

[Mark Pierson]

If I use the names from KM's default function sheet they don't all work and the names on KM's button sheet is remote specific so it does not seem logical that it is the list.

KM aligns buttons positionally, not by name. For example, the generic "tv/vcr" can be used for "tv/vcr", "tv/video", "tv/vid", etc. As Rob has said before, the Buttons list was originally the names from the 15-1994's VCR button map. It's grown from there.

On the Buttons2 sheet, each remote entry has the ability to overide the default name that gets displayed on the Buttons sheet. When KM saves an upgrade, it contains the remote-specific names, not the generic ones.

There's no easy way around this since all the existing KM upgrades are in this format. I don't think there's a true "generic" list of names. However, each button can be identified by a numerical position (column D on the Buttons2 sheet).

Therefore, it might make sense to use something like "button18:TV/Video{A/B}=$20" instead of "tv/vcr:TV/Video{A/B}=$20" in keeping button assignments from one remote to another. If there's no match, then the user will need to redo some/all button assignments, but that would only need to be done once if they resave the file in RM format.

[Mark Pierson]

However, from a distribution point-of-view, it would actually make more sense to distribute the RDFs with IR instead or RM. This is simply because a higher percentage of users need IR than need both IR and RM.

At some point, I think it would make the most sense if IR and RM could somehow share the SAME set of RDF's. I think all that needs to be done to accomplish this is for IR to be able to somehow specify an RDF directory the way RM does.

It might also make sense to provide the RDF's as a separate zip archive instead of including them with both IR and RM.

[jamesgammel]

However, from a distribution point-of-view, it would actually make more sense to distribute the RDFs with IR instead or RM. This is simply because a higher percentage of users need IR than need both IR and RM.

At some point, I think it would make the most sense if IR and RM could somehow share the SAME set of RDF's. I think all that needs to be done to accomplish this is for IR to be able to somehow specify an RDF directory the way RM does.

Could? Somehow? They can share the same rdf's(RM's) For three weeks I've been using a shared rdf file for both IR and RM, and Nils says he has as well. In RM's rdf. folder I just pasted three items from IR3.21a, "Ir.exe", DecodeIR.dll, and gwiopm.sys. RM ignores these three since that don't end with the "rdf" extension. IR, and the other two files are in the same folder, so IR can use all the rdfs. Instead of two folders, one with IR, and one with RM, both with their own rdf's, They both use the same rdf's. To open IR, I just navigate: My documents>RemoteMaster v.71>rdf folder> and click the IR.exe icon.

It might also make sense to provide the RDF's as a separate zip archive instead of including them with both IR and RM.

Agreed. IR for me is about a 9 minute download. RM is about the same. Time could be saved getting revisions if the rdf files weren't included with each revision. I can say the same with regard to image maps as well. One of these days, I hope Nils gets done with the rdf and image map mods; but if we go with standardizing RDF names, this isn't gonna happen soon. If we could grab just the rdf upgrades provided by Nils, (image maps as well) in a seperate zip it would sure help. I'd guess we'd be doing more downloads for these than either new revisions of IR or RM.

BTW, Nils: I saw the latest IR (3.21a) has a more complete rdf for the Toshiba 128b rdf. RM.71 still has the incomplete. Is this in the latest upload you posted for greg? (since I can't look myself).

Jim

[gfb107]

On the Buttons2 sheet, each remote entry has the ability to overide the default name that gets displayed on the Buttons sheet. When KM saves an upgrade, it contains the remote-specific names, not the generic ones.

There's no easy way around this since all the existing KM upgrades are in this format. I don't think there's a true "generic" list of names. However, each button can be identified by a numerical position (column D on the Buttons2 sheet).

If the buttons are in the saved KM files positionally as well, I can just ignore the remote-specific button name, and concentrate on the position to determine the generic button name. This would allow us to use the KM function names as the generic button name, which would make the auto-assign feature work better.

I think I can figure this out now that you've pointed out the positional nature of the buttons, and how I can cross-reference it to the Buttons2 sheet.

[Mark Pierson]

If the buttons are in the saved KM files positionally...

They are. The only caveat is that the list of names is not necessarily the same length from remote/device type to another, or one version to another for that matter. But you're on the right track with your thinking.

[Nils_Ekberg]

BTW, Nils: I saw the latest IR (3.21a) has a more complete rdf for the Toshiba 128b rdf. RM.71 still has the incomplete. Is this in the latest upload you posted for greg? (since I can't look myself).

Jim

All that is in what I uploaded today was maps and images. No RDF's included. I will get the new Toshiba in the next round.

KM aligns buttons positionally, not by name. For example, the generic "tv/vcr" can be used for "tv/vcr", "tv/video", "tv/vid", etc. As Rob has said before, the Buttons list was originally the names from the 15-1994's VCR button map. It's grown from there.

On the Buttons2 sheet, each remote entry has the ability to overide the default name that gets displayed on the Buttons sheet. When KM saves an upgrade, it contains the remote-specific names, not the generic ones.

There's no easy way around this since all the existing KM upgrades are in this format. I don't think there's a true "generic" list of names. However, each button can be identified by a numerical position (column D on the Buttons2 sheet).

Thanks Mark, that clears up why I was getting insonsistent results with the generic name approach.

Greg, I assume that you will persue the positional names for the KM import. In the interim I will experiment and implement with the generic names to go from RM remote to RM remote.

[Mark Pierson]

Could? Somehow? They can share the same rdf's(RM's)

I know that, and I do that myself. But, is it stated in any of the readme's, etc? Will newbies know to do this?

My point is that I think we need to start streamlining the distribution of these tools. I'm always thinking about the people who aren't tech-savvy when it comes to computers. Even some of the simplest things that we take for granted need to be explicitly spelled out to others.

What we really need is an common directory structure that would be used by all these tools. Without some sort of installer app, however, I'm not sure how we could easily accomplish that.