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.03 available
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


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

                    
PostPosted: Thu Sep 10, 2015 10:28 am    Post subject: Reply with quote

Thanks, Alan. This appears to be due to an error in protocols.ini. Open it with a text editor and find the entry starting

Code:
[RC6-M-20n]
PID=00 20
VariantName=short

Change the DeviceTranslator item to

Code:
DeviceTranslator=BitDoubler(0,3,2) \
                 BitDoubler(1,8,12) \
                 BitDoubler(2,2,36) \
                 Translator(2,1,28,3) Translator(2,1,29,3,comp) \
                 Translator(2,1,30,2) Translator(2,1,31,2,comp) \
                 Translator(3,1,08,0) Translator(3,1,10,0,comp) \
                 Translator(3,1,09,0) Translator(3,1,11,0,comp)

The change is that the line BitDoubler(2,2,36) has been moved from below to above the following two Translator entries. You should find that this resolves the issue.
_________________
Graham
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Thu Sep 10, 2015 12:36 pm    Post subject: Reply with quote

Thanks Graham, it fixes RC6-M-20n but the MCE protocol (which I know is a derivative of the RC6-M-20n also fails in the same way. But that doesn't have a DeviceTranslator entry ?

And can you explain why there are 3 separate entries for RC6-M-20n (all of which were broken)

Al
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Fri Sep 11, 2015 6:50 am    Post subject: Reply with quote

alanrichey wrote:
Thanks Graham, it fixes RC6-M-20n but the MCE protocol (which I know is a derivative of the RC6-M-20n also fails in the same way.

I can't work with statements like this, I need actual files in which the error occurs. Please post pairs of files, .rmdu and .bin, as you did for the previous error. I tried a quick test of taking your previous .rmdu file, changing the protocol to MCE, exporting it as a binary upgrade and then importing it again, and it worked without error as far as I could see.

In checking things out I did, however, find another error in protocols.ini. You should delete the entry for [pid: 012A] as this is actually the HCS08 code for MCE variant 2 which is already elsewhere in the file. I don't think this is the cause of whatever you are seeing, but do this deletion to make sure.

Quote:
And can you explain why there are 3 separate entries for RC6-M-20n (all of which were broken)

I don't know about this specific case, but they have different variant names, which usually means that UEI has written more than one executor for a protocol and they have different relationships between device parameters (human readable) and fixed data (the processor-readable equivalent). If the other entries are still broken, then as before, please post files.
_________________
Graham
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Fri Sep 11, 2015 8:36 am    Post subject: Reply with quote

Hi Graham

Sorry about that, I thought any MCE based RMDU file would show that behaviour. RMDU and BIN file now at http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13553.

S2010_PL.BIN was exported from the RMDU file, which uses MCE and Device 38 and OEM2 (which I assume is equivalent to sub-device) of 72. Importing it back gives the same results as we had before.

The other copies of RC6-M-20n had the same errors so I simply corrected them. I assume you will fix the official release ?

And I see the different variant names for the 3 examples ("", "2" & "short"), but when I select a protocol in RM I only get a single choice. How does it know which one to use ? or doesn't it matter ?

Later: just gone in to delete 012A, but there are 2 of them. Which one is wrong ?

Thanks

Al
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Fri Sep 11, 2015 10:31 am    Post subject: Reply with quote

You are making me wonder if we are looking at the same version of protocols.ini. In the version in RMIR v2.03 build 8, there is only one protocol with the heading [pid: 01 2A]. There are others with PID=01 2A but not as the heading in square brackets. It is the one headed [pid: 01 2A] that should be deleted.

There are three protocols headed [RC6-M-20n] but only one of them has the error I described. Of the other two, one does not have any BitDoubler entry and the other does not have a clash between a BitDoubler and a Translator entry (i.e. same first digit, in which case the BitDoubler entry must be before the Translator ones). I will see that the one with the error is corrected in the next release.

The assumption of RM is that all protocols with the same name send the same signals, so it shows the first that supports the processor of the remote. It is only with built-in protocols that the version is critical, as RM must select the one built in to the remote, which it does from the RDF. However, in build 8 only one of the three versions of [RC6-M-20n] has S3C80 code, so that is one shown.

I will look into your new files, but have not yet had time.
_________________
Graham
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Fri Sep 11, 2015 11:28 am    Post subject: Reply with quote

Sorry, just showing my ignorance of the nuts and bolts of the system. I hadn't differentiated between PID=01 2A (The MCE Protocol) and [pid: 01 2A] (The standalone one). Happy now.

Later: Just seen that removing that PID helps a bit. The MCE now imports as RC6-6-32 with a huge sub-device. I assume these are actually the same ?
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Fri Sep 11, 2015 11:51 am    Post subject: Reply with quote

I see that the .bin file you have posted shows up as pid: 01 2A with 8 device parameters, but if I export your .rmdu file as a .bin myself and re-import it, it shows as RC-6-6-32. This appears to be synonymous with MCE, the functions look the same as in the original .rmdu file. So I think that the corrections to protocols.ini that I suggested have affected the export process and it now appears to work OK.

If you still see a problem, please post again.

Edit: I hadn't seen your latest post when I posted this, but we seem to be in agreement.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Fri Sep 11, 2015 12:01 pm    Post subject: Reply with quote

alanrichie wrote:
The MCE now imports as RC6-6-32 with a huge sub-device. I assume these are actually the same ?

I can confirm that they are the same, as the fixed bytes and protocol executor are both the same, which is all that is required for them to have identical behaviour.
_________________
Graham
Back to top
View user's profile Send private message
alanrichey
Expert


Joined: 24 Mar 2008
Posts: 3529
Location: UK/USA

                    
PostPosted: Fri Sep 11, 2015 12:21 pm    Post subject: Reply with quote

Good stuff. Thanks for helping me out.
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Sun Sep 27, 2015 9:53 pm    Post subject: Reply with quote

This .IR file will not load into my RMIR v2.03 build 1. Opens fine in IR.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13529
Task error, Error loading file ... The filename has ext4 in it, but it's for 1994 extender v5.
Quote:
Calculating default fixed data and command lengths
Calculated: Fixed data length = 2, Command length = 1
Using "pid: 01 5E" (01 5E)
Translator.in() index=0 missing parameter value
Translator.in() index=1 missing parameter value
Translator.in() index=2 missing parameter value
Translator.in() index=3 missing parameter value
Error setting new RemoteConfiguration: 41
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException: 41

I don't see pid 015e in this file. Don't know if that's relevant.

Sorry about that RMIR build 1, I'll upgrade soon Embarassed
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
mathdon
Expert


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

                    
PostPosted: Mon Sep 28, 2015 6:58 am    Post subject: Reply with quote

ElizabethD wrote:
This .IR file will not load into my RMIR v2.03 build 1. Opens fine in IR.

The problem lies with the file, not RMIR. If you open it in IR, look at the Devices tab and select VCR/DVD 0573, you will see that the PID is 15E. This protocol is neither built-in nor an upgrade on the Protocols tab. IR doesn't cross-check between Devices and Protocols, but RMIR does. So IR will load it but RMIR will not. I suspect that if you upload this to the remote, the AUX2 device will not work as this is the one that uses this device upgrade.

There is a protocol in protocols.ini with PID=015E, but it is not the missing one. It is a very peculiar one, with 6 fixed bytes and 4 variable bytes, but if you look at the Devices tab in IR, you will see that the VCR/DVD 0573 device has 2 fixed bytes and 1 variable byte. So it looks as if you are missing a protocol upgrade from some other source. The RMIR loading fails because it takes the protocols.ini entry to be the missing protocol and so tries to interpret the device upgrade as if it has 6 fixed and 4 variable bytes. It crashes as the upgrade is not long enough to be interpreted in this way, its end is reached prematurely.

Hope this makes sense.
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2348

                    
PostPosted: Mon Sep 28, 2015 10:43 pm    Post subject: Reply with quote

Explains perfectly well. Thank you.
It's actually not my file, it's Rob's. And he has issued another version anyway at which I was looking, and RMIR has no issue with that one.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Tue Sep 29, 2015 7:59 am    Post subject: Reply with quote

I thought that VCR/0573 code sounded familiar, I took a look at that file, I had accidentally checked the "Protocol > FF" box.

Just for fun, I tried loading my current file into RMIR and it abended too, but I figured out why. I had added an entry to the [SpecialProtocols] section of the RDF so that my Replay Select protocol would be recognized as a special protocol (I added Replay_Sel=01FA) and this worked in IR.exe but caused RMIR to choke. When I deleted the entry from the RDF, the file opened fine in RMIR.

Here's the file that uses the Replay Select special protocol:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13577
_________________
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
View user's profile Send private message Visit poster's website
mathdon
Expert


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

                    
PostPosted: Thu Nov 19, 2015 11:22 am    Post subject: Reply with quote

I have now posted build 10 of RMIR v2.03. This new build is available both as a complete installation file and as an upgrade to any of the earlier builds, both from the link just given. Note that build 9 was not publicly released, so this is the first update since build 8.

The main changes from build 8 are:
  • All bugs notified since build 8 have been fixed
  • For XSight Touch, Nevo and similar remotes, the Buttons panel of the Device Upgrade Editor now allows you to select an icon instead of a text alias for functions from a different device
  • The Option/Font Size Adjustment setting in RM is now preserved between instances
  • An RDF for Nevo C3 has been added and many other RDFs have minor updates
  • Several entries in protocols.ini have had minor corrections
If I have missed any bugs, please post a note in this thread about them.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Nov 19, 2015 5:30 pm    Post subject: Reply with quote

Thanks Graham.

Could you also update this copy please, as SF is blocked for me at work:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13495
_________________
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
View user's profile Send private message Visit poster's website
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, 7  Next
Page 4 of 7

 
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