View previous topic :: View next topic |
Author |
Message |
R2-M0
Joined: 14 Aug 2009 Posts: 92
|
Posted: Fri Jan 20, 2012 4:36 pm Post subject: RM 2.0x & strange Function tab display problem |
|
|
I have strange problems when I load the following file into RM 2.0x and view the "Functions" tab.
http://hifi-remote.com/forums/dload.php?action=file&file_id=10394
If the window is short, then the function list displays OK at first. But if I then start scrolling down one line at a time, things start to go haywire as soon as I scroll past the "hdmi cec" function.
When the "screen size" function should slide into view, I instead see the "hdmi cec" line duplicated again. Any attempts to scroll past this point result in various sections of the list getting duplicated instead of showing the correct contents.
If the RM window is tall enough that the "screen size" function is visible upon first switching to the "Functions" tab, then the display problems start immediately.
I can't for the life of me figure out why this one file is causing problems versus all the other upgrades I've created, none of which exhibit similar behavior.
I'm running Windows Pro SP1 and Java 1.6.0_29.
Thanks for any and all help! |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Fri Jan 20, 2012 5:41 pm Post subject: Re: RM 2.0x & strange Function tab display problem |
|
|
R2-M0 wrote: | I have strange problems when I load the following file into RM 2.0x and view the "Functions" tab. |
I saw the same symptoms. Though, I noticed it goes away when I change the .rmdu extension to .txt and delete the following lines through notepad...
- Function.38.hex=A3 05 (Screen Size)
- Function.39.hex=79 05 (a/v select)
- Function.46.hex=F1 05 (Sleep)
- Function.47.hex=DB 05 (pip freeze)
- Function.48.hex=FB 05 (pip split)
- Function.49.hex=5B 05 (pip swap)
- Function.50.hex=1B 05 (pip shift)
...then save the file back as an RMDU file are re-open in Remote Master. It seems like RM doesn't like those particular codes because it will go haywire again if I try and reapply them. Notice that they all end in 05? Apparently, it doesn't like any hex code if the the last byte is higher then 03h. _________________ 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.)
Last edited by eferz on Fri Jan 20, 2012 5:52 pm; edited 1 time in total |
|
Back to top |
|
|
Dilligaf
Joined: 05 Aug 2003 Posts: 79 Location: Michigan |
Posted: Fri Jan 20, 2012 5:50 pm Post subject: |
|
|
I opened the file with notepad and deleted function 34 and it works now, are you sure the values for hdmi cec are correct?
Mike |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Fri Jan 20, 2012 6:01 pm Post subject: |
|
|
Dilligaf wrote: | I opened the file with notepad and deleted function 34 and it works now, are you sure the values for hdmi cec are correct? |
Check your results. Function 34 is Exit, 37 is hdmi-cec. Neither of which are actually experiencing the issue. Its the hex codes which end in "05" which are causing the symptoms. _________________ 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 |
|
|
Dilligaf
Joined: 05 Aug 2003 Posts: 79 Location: Michigan |
Posted: Fri Jan 20, 2012 6:34 pm Post subject: |
|
|
Yeah, I fat fingered it, it was 37. Upon looking further the other lined aren't showing. You're probably right about the 05.
Mike |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Fri Jan 20, 2012 8:11 pm Post subject: Re: RM 2.0x & strange Function tab display problem |
|
|
R2-M0 wrote: | I have strange problems when I load the following file into RM 2.0x and view the "Functions" tab. |
Found a match and recorded the IR signals with the JP1 tools to create the respective files.
It appears you're were having a problem trying to cram in 170.94 commands in with the upgrade. Since you already have 170.91 and 170.92 device prefixes in the Pioneer Mix protocol settings, I don't believe there's a way to fit other commands into one upgrade. Most likely, you'll have to split the upgrade into two parts to support the PIP features. So, I used the Pioneer DVD protocol for 170.94 commands which all look relevant to the PIP functions. Not sure if what I did was correct or if I am using the correct protocol but it seem to me like the only way.
On a side note, I hate the Pioneer protocol. _________________ 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 |
|
|
R2-M0
Joined: 14 Aug 2009 Posts: 92
|
Posted: Fri Jan 20, 2012 8:23 pm Post subject: |
|
|
I based that upgrade off of this one in the file section...
http://hifi-remote.com/forums/dload.php?action=file&file_id=5416
...which also exhibits the same behavior.
Since I still have the original OEM remote, I also used IR learning to re-examine the problematic "05" functions. And like eferz, I discovered that these functions seem to use an extra prefix command/OBC of 94 -- which presents a problem since Pioneer Mix apparently only allows the choice of two prefix commands.
But I've had this particular upgrade for a couple of years now, and it's loaded in my RCRP05B and working quite nicely at the moment. So I can't understand how it is that I was originally able to use this upgrade in RM (complete with the "05" byte commands), upload it to my remote via IR, and have all the commands work just fine. Did something change in protocols.ini along the way that corked this up?
Edit: Looking at protocols.ini, I think I've found the problem.
There are two entries for "Pioneer MIX" in there. Both have PID=00 7E. One has a VariantName=2 (which also means it has the exact same PID and variant as "Pioneer DVD2"). The second "MIX" protocol has a VariantName=3... and it allows you specify up 4 prefix Cmds, and supports values of $04 and $05 in the last byte.
Unfortunately, RM 2.0x doesn't appear to be allowing access to this second version of "Pioneer MIX" for some reason. If I can get to that, I think everything would work just dreamily. |
|
Back to top |
|
|
R2-M0
Joined: 14 Aug 2009 Posts: 92
|
Posted: Fri Jan 20, 2012 9:02 pm Post subject: |
|
|
I renamed the second "Pioneer MIX" variant in "protocols.ini" to "Pioneer MIX2". Then I changed the "Protocol.name" and "Protocol.variantName" lines in the upgrade appropriately. Restarted RM and reloaded the upgrade. Bingo! I now see Cmd3 and Cmd4 options on the "Setup" tab. Set Cmd3 to "94", and now everything's looking good again.
So somewhere along the way, either "protocols.ini" or RM's interpretation of it changed. I guess it's just a matter of getting these naming changes (or something very much like them) applied to the official protocols.ini file that comes bundled with RM 2.0x going forward. |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Fri Jan 20, 2012 9:19 pm Post subject: |
|
|
R2-M0 wrote: | I renamed the second "Pioneer MIX" variant in "protocols.ini" to "Pioneer MIX2". Then I changed the "Protocol.name" and "Protocol.variantName" lines in the upgrade appropriately. Restarted RM and reloaded the upgrade. Bingo! I now see Cmd3 and Cmd4 options on the "Setup" tab. Set Cmd3 to "94", and now everything's looking good again.
So somewhere along the way, either "protocols.ini" or RM's interpretation of it changed. I guess it's just a matter of getting these naming changes (or something very much like them) applied to the official protocols.ini file that comes bundled with RM 2.0x going forward. |
Interesting. I wonder how many other protocols are hidden because of this. _________________ 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 |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3367
|
Posted: Fri Jan 20, 2012 11:03 pm Post subject: |
|
|
I looked at a protocols.ini file from March 2008. The entire Pioneer section is identical to that of the 2.02Beta distribution. So if protocols.ini is wrong, it has been that way for a long time. |
|
Back to top |
|
|
R2-M0
Joined: 14 Aug 2009 Posts: 92
|
Posted: Sat Jan 21, 2012 8:44 am Post subject: |
|
|
I'm not really all that surprised to find out that protocols.ini has been this way for a while now. As I said, the problem could easily be caused by a change in RMs processing of the file.
It looks like RM keys its protocol table off the protocol names, rather than PID + variantName. So as long as the names are different, RM allows access to everything.
But there are many instances of protocol name collisions in the .ini file -- usually with different variantNames, but not always (there are two "Dish Network Combo" entries both of which have PID=00 02 and VariantName=5, for example). And in those cases, it looks like RM only displays one of the options.
Seems as though RM probably should be using something like "name (variantName)" as the key when it builds its protocol table. That would help, but it still looks like some protocols.ini cleanup is in order. Consider the following from near the very beginning of the file:
Code: | Aiwa: PID=00 5E
Aiwa: PID=00 5E, VariantName=2
Aiwa2: PID=00 5E, VariantName=2
|
Three protocols, all with the same PID, but with two different names and two different variants. No wonder RM gets confused! |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Thu Mar 08, 2012 6:47 pm Post subject: |
|
|
R2-M0 wrote: | It looks like RM keys its protocol table off the protocol names, rather than PID + variantName. So as long as the names are different, RM allows access to everything. |
It looks like mathdon has resolved this problem with RM/RMIR 2.02 Beta 1.5r. However, the original upgrade was saved with the incorrect protocol due to the previous bug.
Code: | Protocol.name=Pioneer MIX
Protocol.variantName=2
ProtocolParms=170 175 90 91
FixedData=AA A5 0A 25
|
I've edited the respective file in the download section to make the following changes:
Code: | Protocol.name=Pioneer MIX
Protocol.variantName=3
ProtocolParms=170 175 90 91 94 null
FixedData=AA A5 25 85 00 0A
|
The new versions of Remote Master and the device upgrade will load appropriately now. _________________ 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 |
|
|
landolfi
Joined: 12 Apr 2006 Posts: 57 Location: Chicagoland |
Posted: Fri Apr 13, 2012 12:29 am Post subject: |
|
|
I did a search and found this post because I am having really flaky display behavior when trying to open the Functions tab in RMIR 2.02 Beta 1.5q, and yes, I am using the Pioneer MIX protocol. This looks very similar to what was happening when RMIR was using the wrong MIX variant, and I'm getting similar behavior because EFCs that work on other remotes don't work here. Also, I seem to be having the weird display behavior on all versions of that particular Pioneer RMDU file, even ones using the right variant and that work. I notiiced the 1.5r and will try the latest version. |
|
Back to top |
|
|
|