RM/RMIR v2.02 Beta now available!

[eferz]

If I do that I get an error that "no rdf for remote with signature" is shown.

Have you downloaded the necessary RDFs (http://www.hifi-remote.com/forums/dload ... le_id=9353) and gone into Remote Master > Options > Folders RDF Folder... or RMIR > File > Set directory > RDF Path... and chosen the proper location?

[3FG]

Jeff,
I have a 1056B01 black, backlit, learner. I believe that I have followed your instructions exactly. RMIR begins the download, and then asks me to choose from a list of 4 remotes (1055, 11055, 1056 black, 1056 silver). Once I select a remote, the download finishes. So I'm not seeing the behavior you are.

Can you try this with IR.exe to see what signature is actually in memory? Then you can compare with the signature you see when downloading with the devices tab open in RMIR.

I think that there may have been some privately distributed beta versions. Would you do Help\About and post here which Beta you're using? On the same About screen, it shows the directories for RDF and Image/Map files. Please make sure that the directories correspond to the ones that have the RDFs.

Finally, before starting RMIR, first erase rmaster.err, which is in the same directory as remotemaster.jar. Then, when you get the message that no matching RDF is found, do nothing else in RMIR, but copy rmaster.err to another file name and then post that file here. Maybe one of us can spot a problem

[greenough1]

Hi Guys,
This morning I repeated the experiment I did yesterday that produced the error, but first deleting rmaster.err

* 981 reset the atlas
* launch RM-IR
* attempt to download without accessing any other menu.

this time it worked as 3FG states, select from the following list of remotes. I choose the correct one and it works.

I'm using RM-IR v2.02 beta. Here's the rest of the about screen:

RDFs loaded from C:\Users\Jeff\Documents\Zip backup\Remote\Remote Stuff v2\New Stuff\rdfs required for RM-IR and IR
Images and Maps loaded from C:\Users\Jeff\Documents\Zip backup\Remote\Remote Stuff v2\New Stuff\maps and images for RM-IR v 1.32
DecodeIR version 2.43
Interfaces:
JP1.X Serial version 0.18
JP1 USB version 0.031
JP1 Parallel version 0.02
System Properties:
java.version = "1.6.0_29"
java.vendor = "Sun Microsystems Inc."
os.name = "Windows Vista"
os.arch = "x86"

I'm not what has changed from last night. I've not rebooted the machine. The batteries were out of the remote overnight, but that shouldn't matter.

I repeated the test last night 3 times successfully. I was surprised I was getting an error as it has worked before, but I'd always gone into another menu first.

Regardless, I set up a back bedroom remote with RM-IR last night using atlas extender 2.13 (the latest). I'm liking this tool alot! Thanks for verifying that it was user error.
Best,
jeff

[eferz]

I was wondering if it was possible to augment Remote Master to support the various SlingRemote skins? The last time I had a request to recode a bin file to support one of the SlingRemote skins, I had to push it off on Alan because he is more experienced in that sort of thing. Last night, I decided to button down and learn the process.

On the Slingbox, the buttons' keymap are assigned a command. Then the commands are assigned a string which identifies the button's name. I know this sounds far more complicated then it needs to be. But, they do this to be able to adjust the remote for different skins and button names based on the setup code. To give you an idea of what I'm talking about here's an excerpt of the Remote.XML file for four of the 81 keymaps and 270 strings in the Default skin.

Code: Select all

<KeyMaps>
    <KeyMap id="Global.UEI">
      <Map key="074" cmd="id.remote.custom.22" />
      <Map key="075" cmd="id.remote.custom.23" />
      <Map key="076" cmd="id.remote.custom.24" />
      <Map key="077" cmd="id.remote.custom.25" />
    </KeyMap>
</KeyMaps>
<Strings>
    <String cmd="id.remote.custom.22" value="Custom22;Custom" />
    <String cmd="id.remote.custom.23" value="Custom23;Custom" />
    <String cmd="id.remote.custom.24" value="Custom24;Custom" />
    <String cmd="id.remote.custom.25" value="Custom25;Custom" />
</Strings>

Above is the basic remote layout for four buttons. Now if the setup code starts with "C" then it represents a Cablebox. The referenced keymaps for it will get overridden then the commands are subsequently associated to different button names.

Code: Select all

<KeyMap id="CABLEBOX.UEI">
      <Map key="074" cmd="id.remote.red" />
      <Map key="075" cmd="id.remote.green" />
      <Map key="076" cmd="id.remote.yellow" />
      <Map key="077" cmd="id.remote.blue" />
</KeyMap>
<Strings>
    <String cmd="id.remote.red" value="Red;" />
    <String cmd="id.remote.yellow" value="Yellow;" />
    <String cmd="id.remote.green" value="Green;" />
    <String cmd="id.remote.blue" value="Blue;" />
</Strings>

For the default skin there are twelve possible keymaps which could take precedence over the default configuration. When a setup code is specified and has a different SlingRemote skin associated then its values will overlap default remote. This is demonstrated in the example below using the V1128 setup code for the Sony-HXD870 SlingRemote skin.

Code: Select all

<KeyMaps>
    <KeyMap id="idmap.sony.HXD870.UEI">
      <Map key="074" cmd="id.remote.day.up" />
      <Map key="075" cmd="id.remote.tvpause" />
      <Map key="076" cmd="id.remote.dub" />
      <Map key="077" cmd="id.remote.zoom" />
    </KeyMap>
</KeyMaps>
</Strings>
    <String cmd="id.remote.day.up" value="Day +" />
    <String cmd="id.remote.tvpause" value="TV Pause;TV" />
    <String cmd="id.remote.dub" value="DUB" />
    <String cmd="id.remote.zoom" value="Zoom;Misc" />
</Strings>

So far, there are 92 recorded SlingRemote skins for the SlingPlayer. I was going to start creating .img and .map files for each of them until I noticed that the button mappings and names for RM are actually contained within each .rdf file. This means I would need to create a Remote Definition File for each SlingRemote skin and each processor type. I was hoping RM could be enhanced to use an additional layer similar to Sling's method to enable the name to button translation.

For reference, I uploaded an archive with each of the Remote.XML files for each SlingRemote skin (http://www.hifi-remote.com/forums/dload ... e_id=10390).

[mathdon]

I was wondering if it was possible to augment Remote Master to support the various SlingRemote skins?

I would like to leave this one for Greg to answer, as he added the present Slingbox support. I barely even know what a Slingbox is, I'm afraid.

[eferz]

I would like to leave this one for Greg to answer, as he added the present Slingbox support. I barely even know what a Slingbox is, I'm afraid.

Alright, thanks. But, if we wanted to exclude this as a "proprietary Slingbox implementation" then this mechanism could be used for any current or future JP1 remotes whose RDF or Extender is the same except for the image map and button names. This would reduce the need for multiple permutations of the same file where only those respective values are different.

This is similar to the current implementation where multiple image maps are currently referenced, like in the "KASAKAS0 (URC-9960 B01 One For All Kameleon).rdf". Except with the added provision to replace the displayed button names in the Layout and Buttons tabs. Maybe by implementing a new section in the map files or a separate file which would store these values.

The only proprietary Slingbox implementation would be set the proper skin if the user's setup code and device type is matched, or change the setup code and device type if a different skin is selected.

So, for example, the current BINPL (Slingbox with UEI PL Chip).rdf has the button names listed as

Code: Select all

Red=74,
Green=75,
Yellow=76,
Blue=77,

But since these names are only appropriate for the Cable, SAT, and PVR device types. I would change the original RDF to match the UEI global profile which as such:

Code: Select all

Custom23=75,
Custom24=76,
Custom25=77,
Custom26=78,

Then create a suitable Slingbox-Cbl/SAT/PVR-menu.map and jpeg where the overriding values were listed in the map file or a separate one. Any value which is not referenced would keep the original values from the RDF file.

Code: Select all

Red=74,
Green=75,
Yellow=76,
Blue=77,

And for skins which use a specific setup code like the V1128

Code: Select all

Setup Code=V1128,
Day +=74,
TV Pause=75,
DUB=76,
Zoom=77,

[R2-M0]

Just wanted to include a reference in this thread to a problem I uncovered with RM 2.0x's protocol.ini file. It results in at least two protocols (Pioneer DVD2 and the 4 Cmd variant of Pioneer MIX) being "hidden" from RM.

A full discussion of the symptoms that led to the discovery and the solution I used to work around it can be found in the following thread:

http://hifi-remote.com/forums/viewtopic.php?t=13814

[eferz]

I'd like to reiterate that there's probably a bug in RM/RMIR associating the correct Pioneer Mix variant when opening or importing an RMDU file which utilizes variant 3. The current work around is to place the variant 3 section of the Pioneer Mix before variant 2 in the protocol.ini file. However, I'm not sure how that will affect RMDUs with variant 2.

Details are described in the following threads:

• EFC codes don't work across remotes?
• RM 2.0x & strange Function tab display problem

[mathdon]

I was in the process of installing an extender on an Atlas 1055 3033 remote and ran into problems when testing it out. I found that the macros I set for device keys in RMIR didnt work. I saved the file as an IR file and opened in IR and the macros read completely different. I reset them to what I wanted in IR and saved, I then opened the saved IR file in RMIR and the macros read incorrectly. I uploaded to the remote without changing them again and now the remote works. I'm using v213 of the atlas extender. Here is the file http://www.hifi-remote.com/forums/dload ... e_id=10128

Mike

PS. I merged the extender in RMIR and the default macros looked weird so I reset them, after fixing in IR the macros look like they did originally

I would like to investigate this issue, but this narrative is not enough to go on. If Dilligaf, or anyone else, can provide me with files and an explanation of how I can reproduce the faulty behaviour, I will look into it. The file mentioned in this post is not sufficient, it gives me no idea of what I am supposed to be looking for.

[Dilligaf]

OK, open the posted file in RMIR and save it as an IR file then open the IR file in IR803. Compare the macros in RMIR and IR and you will see that they are totally different. I have RM and RMIR using the same rdf files. It appears that IR is correct and for some reason RMIR is wrong. I hope this makes sense.

Mike

I was in the process of installing an extender on an Atlas 1055 3033 remote and ran into problems when testing it out. I found that the macros I set for device keys in RMIR didnt work. I saved the file as an IR file and opened in IR and the macros read completely different. I reset them to what I wanted in IR and saved, I then opened the saved IR file in RMIR and the macros read incorrectly. I uploaded to the remote without changing them again and now the remote works. I'm using v213 of the atlas extender. Here is the file http://www.hifi-remote.com/forums/dload ... e_id=10128

Mike

PS. I merged the extender in RMIR and the default macros looked weird so I reset them, after fixing in IR the macros look like they did originally

I would like to investigate this issue, but this narrative is not enough to go on. If Dilligaf, or anyone else, can provide me with files and an explanation of how I can reproduce the faulty behaviour, I will look into it. The file mentioned in this post is not sufficient, it gives me no idea of what I am supposed to be looking for.

[mathdon]

OK, open the posted file in RMIR and save it as an IR file then open the IR file in IR803. Compare the macros in RMIR and IR and you will see that they are totally different. I have RM and RMIR using the same rdf files. It appears that IR is correct and for some reason RMIR is wrong. I hope this makes sense.

I thought that is what you meant in your previous post, so I did it and the macros are identical in both RMIR and IR:

[Dilligaf]

I just checked again and still see it. Did you put the v2.13 extender rdf in your rdf directory? I see extender v0.2 in your IR picture above. Maybe thats my problem, IR and RMIR may be using different rdf files. Here's a pic



Here's the RDF

http://www.hifi-remote.com/forums/dload ... e_id=10792

Mike

[Dilligaf]

Just wanted to add that in IR when the file is opened it asks which rdf to use, in RMIR ir just opens without asking which one.

Mike

[mathdon]

Sorry, I had an out-of-date RDF. I've now put the current ones in my RDF folder and repeated the experiment. Both RMIR and IR asked me to choose the remote from a list (a longer list for RMIR than IR). I chose the same in both cases and still get identical macros, though different from the ones with the old RDF. Here's the result:



So it is definitely a matter of RMIR and IR for you selecting different RDFs. I will look into the selection criteria to see if I can find why RMIR and IR offer different lists, but if there is an RMIR bug it is in this selection process, not elsewhere in the macro processing.

Edit: I've got it. Your .rmir file contains the remote's name:

Code: Select all

[General]
Remote.name=Atlas 5 Day URC-1055 JP1.3 3033  extender
Remote.signature=3A333A33 

and you still have an old rdf with this exact name:

3A333A33 (Atlas 5 Day URC-1055 JP1.3 3033 extender).rdf

in your RDF folder as well as the new one. If RMIR can match the name, it selects that RDF, no questions asked. The .ir file doesn't have names, IR.exe extracts the signature and some other info from the hex data so it has less to match on and offers a choice of what it finds, which will include both the old and new RDFs.

I deleted the old one when I put in the new one, so got a choice. If you delete the old RDF from your folder, RMIR won't find a name match and will offer you a choice so that you can choose the correct one.

[Dilligaf]

Deleting the old one fixed it. This issue isn't mentioned anywhere in the documentation, is this an extender issue or? Where does the mane in the rdf come from? Should the extender merge operation edit the name in the rmir file to match the merged extender? Sorry, lots of questions and few answers.

Mike