JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RM/RMIR v2.02 Beta now available!
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Wed Jan 04, 2012 11:34 pm    Post subject: Reply with quote

greenough1 wrote:
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.php?action=file&file_id=9353) and gone into Remote Master > Options > Folders RDF Folder... or RMIR > File > Set directory > RDF Path... and chosen the proper location?
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3365

                    
PostPosted: Thu Jan 05, 2012 1:38 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
greenough1



Joined: 30 Jan 2005
Posts: 659

                    
PostPosted: Thu Jan 05, 2012 10:03 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Thu Jan 19, 2012 5:58 pm    Post subject: Reply with quote

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:
<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:
<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:
<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.php?action=file&file_id=10390).
_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Jan 20, 2012 11:37 am    Post subject: Reply with quote

eferz wrote:
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.
_________________
Graham
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Fri Jan 20, 2012 2:36 pm    Post subject: Reply with quote

mathdon wrote:
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:
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:
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:
Red=74,
Green=75,
Yellow=76,
Blue=77,

And for skins which use a specific setup code like the V1128
Code:
Setup Code=V1128,
Day +=74,
TV Pause=75,
DUB=76,
Zoom=77,

_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 92

                    
PostPosted: Fri Jan 20, 2012 9:45 pm    Post subject: Problem with protocols.ini Reply with quote

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
Back to top
View user's profile Send private message
eferz
Expert


Joined: 03 Jun 2010
Posts: 1078
Location: Austin, Texas

                    
PostPosted: Tue Feb 21, 2012 11:49 am    Post subject: Re: Problem with protocols.ini Reply with quote

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:

_________________
Remotes; JP1.2: Comcast URC-1067, JP1.3: Insignia NS-RC02U-10A, JP1.4 OARI06G, JP2.1: Cox URC-8820-MOTO (still trying to figure out how to make them self-aware.)
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Mar 07, 2012 2:27 pm    Post subject: Reply with quote

Dilligaf wrote:
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.php?action=download&file_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.
_________________
Graham
Back to top
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

                    
PostPosted: Wed Mar 07, 2012 4:56 pm    Post subject: Reply with quote

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

mathdon wrote:
Dilligaf wrote:
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.php?action=download&file_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.
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Mar 07, 2012 6:31 pm    Post subject: Reply with quote

Dilligaf wrote:
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:




_________________
Graham
Back to top
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

                    
PostPosted: Wed Mar 07, 2012 6:57 pm    Post subject: Reply with quote

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.php?action=file&file_id=10792

Mike
Back to top
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

                    
PostPosted: Wed Mar 07, 2012 9:18 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Thu Mar 08, 2012 11:57 am    Post subject: Reply with quote

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:
[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.
_________________
Graham
Back to top
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

                    
PostPosted: Thu Mar 08, 2012 1:48 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 3 of 6

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control