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 2.0x & strange Function tab display problem

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
R2-M0



Joined: 14 Aug 2009
Posts: 81

PostPosted: Fri Jan 20, 2012 4:36 pm    Post subject: RM 2.0x & strange Function tab display problem Reply with quote

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


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

PostPosted: Fri Jan 20, 2012 5:41 pm    Post subject: Re: RM 2.0x & strange Function tab display problem Reply with quote

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
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

PostPosted: Fri Jan 20, 2012 5:50 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Jan 20, 2012 6:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
Dilligaf



Joined: 05 Aug 2003
Posts: 79
Location: Michigan

PostPosted: Fri Jan 20, 2012 6:34 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Jan 20, 2012 8:11 pm    Post subject: Re: RM 2.0x & strange Function tab display problem Reply with quote

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
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 81

PostPosted: Fri Jan 20, 2012 8:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 81

PostPosted: Fri Jan 20, 2012 9:02 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Jan 20, 2012 9:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3255

PostPosted: Fri Jan 20, 2012 11:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
R2-M0



Joined: 14 Aug 2009
Posts: 81

PostPosted: Sat Jan 21, 2012 8:44 am    Post subject: Reply with quote

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


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

PostPosted: Thu Mar 08, 2012 6:47 pm    Post subject: Reply with quote

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
View user's profile Send private message
landolfi



Joined: 12 Apr 2006
Posts: 48
Location: Chicagoland

PostPosted: Fri Apr 13, 2012 12:29 am    Post subject: Reply with quote

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
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
Page 1 of 1

 
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
Get Smart! the band's official homepage Rockabilly Central