RM 2.0x & strange Function tab display problem

R2-M0 · Post by **R2-M0** » Fri Jan 20, 2012 3:36 pm

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 ... e_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!

eferz · Post by **eferz** » Fri Jan 20, 2012 4:41 pm

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.

Dilligaf · Post by **Dilligaf** » Fri Jan 20, 2012 4:50 pm

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

eferz · Post by **eferz** » Fri Jan 20, 2012 5:01 pm

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.

Dilligaf · Post by **Dilligaf** » Fri Jan 20, 2012 5:34 pm

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

eferz · Post by **eferz** » Fri Jan 20, 2012 7:11 pm

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.

ICT file: http://www.hifi-remote.com/forums/dload ... e_id=10395
RMDU 1 file: http://www.hifi-remote.com/forums/dload ... e_id=10396
RMDU 2 file: http://www.hifi-remote.com/forums/dload ... e_id=10397

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.

R2-M0 · Post by **R2-M0** » Fri Jan 20, 2012 7:23 pm

I based that upgrade off of this one in the file section...

http://hifi-remote.com/forums/dload.php ... le_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.

R2-M0 · Post by **R2-M0** » Fri Jan 20, 2012 8:02 pm

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.

eferz · Post by **eferz** » Fri Jan 20, 2012 8:19 pm

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.

3FG · Post by **3FG** » Fri Jan 20, 2012 10:03 pm

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.

R2-M0 · Post by **R2-M0** » Sat Jan 21, 2012 7:44 am

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: Select all

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!

eferz · Post by **eferz** » Thu Mar 08, 2012 5:47 pm

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: Select all

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: Select all

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.

landolfi · Post by **landolfi** » Thu Apr 12, 2012 11:29 pm

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.

JP1 Remotes

RM 2.0x & strange Function tab display problem

RM 2.0x & strange Function tab display problem

Re: RM 2.0x & strange Function tab display problem

Re: RM 2.0x & strange Function tab display problem