RMIR: Prototype IR function in RM

Post by **ElizabethD** » Tue Jan 20, 2015 3:24 pm

Hello Greg,
I completely agree with your comments about keymoves for other devices. And it took just seconds to rebuild in RMIR.
I used that sheet, likely, simply because it was there. Perhaps I read some forum post about it.
Here's a twist. Suppose I don't code shifted functions on the Buttons sheet, but do so on that (rarely used) keymoves tab, a legitimate thing to do if you read the instructions on the right side there. Those keymoves would vanish in translation to RM/RMIR.
What if someone downloads a KM file from the file section that contains such a keymove sheet, doesn't have Excel to compare, and counts on the translation to RMIR be good?

Graham,
Chugging along here, I'm having serious issue in alpha23c with a manual protocol adoption. Should I retry in alpha28 or start pesting you again with the details I now have collected?

Post by **vickyg2003** » Tue Jan 20, 2015 6:19 pm

ElizabethD wrote:using alpha27c

New question: This TV upgrade in KM has 3 buttons on the Keymove tab, they're not in the normal Upgrade section (shifts usually), but in the Keymoves section to copy/paste.
http://www.hifi-remote.com/forums/dload ... e_id=13099
Other than manually - how do I bring it in? No big deal really but I thought I'll ask. It's confusing me when .rmdu files don't have Keymoves tab, so ones such as this might get lost in translation from KM-IR to RM-RMIR system.
Since you don't have KM - screenie of the tab posted.
When importing keymoves such as these, IR reminds that the device (AUD) has to be in.
http://www.hifi-remote.com/forums/dload ... e_id=13100

Liz, IR doesn't appear to handle this either.

I think RMIR is probably way better at this simply because you can assign your keymoves by using the function name.

I really haven't run across any upgrades containing keymoves.

Post by **ElizabethD** » Wed Jan 21, 2015 9:17 pm

Vicky, continuing the now OT subject:
I think it won't work on that TV file because of seven-byte keymoves in Atlas, hence the "data not terminated correctly" error.
But import from KM into IR works perfectly on 8910/9910 six-byte keymoves, as well as (looong ago) 7800 six-byte keymoves from ECC.

Post by **mathdon** » Thu Jan 22, 2015 3:03 am

ElizabethD wrote:I'm having serious issue in alpha23c with a manual protocol adoption. Should I retry in alpha28 or start pesting you again with the details I now have collected?

You will need Alpha 28 if you want to see the revised behaviour of the Device Upgrade Editor. If you think that your serious issue might be caused by a bug in RM/RMIR then post the details in this thread. If, however, it is a question of needing help with how to do something then a different thread would be better.

gfb107 · Post by **gfb107** » Thu Jan 22, 2015 8:48 am

ElizabethD wrote:Hello Greg,Suppose I don't code shifted functions on the Buttons sheet, but do so on that (rarely used) keymoves tab, a legitimate thing to do if you read the instructions on the right side there. Those keymoves would vanish in translation to RM/RMIR.
What if someone downloads a KM file from the file section that contains such a keymove sheet, doesn't have Excel to compare, and counts on the translation to RMIR be good?

It doesn't mesh with RMIR's concept of a device upgrade. In an RMIR device upgrade, there are no keymoves, only function-to-button assignments. There is no way to force a function assignment to be a keymove.

So the best we could do for each keymove is

If there is already a function assigned to the button, replace it
Otherwise, assign the function to the button

Whether or not that results in a keymove depends on whether or not the button is in the remote's keymap. We could show a warning message that this happened.

I personally don't think it is worth the effort to implement this. As, you say, it's rarely used.

Post by **ElizabethD** » Thu Jan 22, 2015 1:08 pm

mathdon wrote:
ElizabethD wrote:I'm having serious issue in alpha23c with a manual protocol adoption. Should I retry in alpha28 or start pesting you again with the details I now have collected?
You will need Alpha 28 if you want to see the revised behaviour of the Device Upgrade Editor. If you think that your serious issue might be caused by a bug in RM/RMIR then post the details in this thread. If, however, it is a question of needing help with how to do something then a different thread would be better.

OK. I think it's a bug.

Graham, before this falls off my radar, could you peek at the tail end of post on p.49 (Fri Jan 16, 2015 10:41 pm) regarding point 1c, please.

Post by **vickyg2003** » Thu Jan 22, 2015 3:59 pm

ElizabethD wrote:
Graham, before this falls off my radar, could you peek at the tail end of post on p.49 (Fri Jan 16, 2015 10:41 pm) regarding point 1c, please.

mathdon wrote:
1c. some keymoves, such as DSM, got moved to Special, and some Special got moved to keymoves. I think it's all ok, just different.
Special Functions are coded as keymoves, so this is not surprising, but if you want to post an example for me to check out, please do so.

Actually I was just reporting what I saw. I'm actually less puzzled by the SP becoming keymoves, than the DSMs becoming Special Functions.
Most likely it's all fine. I didn't yet get to uploading from RMIR, nor building RMIR, since I'm still in the discovery of old files mode for the remotes that work here.
Two screenshots for you
http://www.hifi-remote.com/forums/dload ... e_id=13055

Liz, my guess would be that there is something odd in your RDF or in your protocols names in your IR file to cause that behavior. I see the screen shots, but I didn't find where you posted your files. Pure guess work on my part suggests that the protocols don't match up with the protocols listed in the RDF for DSM. Perhaps you tweaked it and gave it another name. Its always easier to work from files than it is from a screen print.

Post by **ElizabethD** » Thu Jan 22, 2015 9:25 pm

Yikes. Vicky, I'm so sorry!
I missed putting one file into that zip, so just resubmitted the whole package.
One picture is about Atlas, one about 6131.
http://www.hifi-remote.com/forums/dload ... e_id=13105
The 6131 is what was missing. If RDF issue, it might be because Hal built DSM into the 6131 extender. But I doubt it since just recently I reloaded this file back into 6131 with current RDFs in place and it works fine.

Post by **vickyg2003** » Fri Jan 23, 2015 6:44 am

Okay Liz, I can't duplicate your 6131 picture, and I opened it with all 4 possible RDF's available. My guess is you have a bad RDF. Every single one of them opens with the DSM's in the Special Protocols. My PVR0xxxx RDFs are dated May 2010, are yours newer or older?

Post by **vickyg2003** » Fri Jan 23, 2015 7:37 am

More:

I couldn't open your Atlas extender file due to RDF errors on my machine. UncleMiltie decided to not submit his RDFs for management by the RDF librarian. That is so the Librarian isn't introducing errors that could corrupt extender installs that could potentially brick your remote.

So as things change in RMIR, the JP1.3 extender RDFs may not be updated with the latest protocol variant information, white space problems don't get corrected unless UncleMiltie does it himself.

RDF writing is a mystery to me, even though I've done it a few times. I write oldfashioned extenders that go away on a 981. UncleMilties are a bit more complicated and need special care in installation and activation and deactivation. If I were in his place, I'd reserve the right to maintain my own RDFs too.

Post by **mathdon** » Fri Jan 23, 2015 12:44 pm

vickyg2003 wrote:I couldn't open your Atlas extender file due to RDF errors on my machine. UncleMiltie decided to not submit his RDFs for management by the RDF librarian. That is so the Librarian isn't introducing errors that could corrupt extender installs that could potentially brick your remote.

Is this real or just speculation? I cannot bring myself to believe it. Since the RDFs contain errors, namely spaces that are not in accord with the RDF Spec and which crash RM/RMIR, the idea that they may be corrupted by changes made by the RDF Librarian (or other experts with the authority to update the SVN) is surprising. BTW RMIR v2.03 Alpha 28, and also Alpha 27c, will handle these spurious spaces.

xnappo · Post by **xnappo** » Fri Jan 23, 2015 1:39 pm

That is real. It was more to do with RDF versions not matching extender versions if I recall.

Post by **vickyg2003** » Fri Jan 23, 2015 2:42 pm

mathdon wrote:
vickyg2003 wrote:BTW RMIR v2.03 Alpha 28, and also Alpha 27c, will handle these spurious spaces.
I had lots of errors thrown in RMIR Alpha 28 trying to open Liz's file, but I probably just have the wrong version of RDF for the extender that Liz is using.

Post by **ElizabethD** » Fri Jan 23, 2015 3:15 pm

ElizabethD wrote:Yikes. Vicky, I'm so sorry!
I missed putting one file into that zip, so just resubmitted the whole package.
One picture is about Atlas, one about 6131.
http://www.hifi-remote.com/forums/dload ... e_id=13105
The 6131 is what was missing. If RDF issue, it might be because Hal built DSM into the 6131 extender. But I doubt it since just recently I reloaded this file back into 6131 with current RDFs in place and it works fine.

Vicky,
Are you saying that in IR my DSMs are not under keymoves? Because here they're under keymoves.
It's all related to old IR (2006? 2007?). Probably not to RDF (I still have 2008 in my backup, but use current ones). When this extender came out, IR couldn't see DSM in Special Protocols, so one simple solution was to code it in KM ( I just rechecked extender readme). I guess I never changed my ir files.
The main problem with jp1 is that it all works regardless of any old mess

My puzzle 1c is solved - I now understand why RMIR moved them, so thank you much.

Post by **ElizabethD** » Fri Jan 23, 2015 4:21 pm

vickyg2003 wrote:... I probably just have the wrong version of RDF for the extender that Liz is using.

Vicky, in Atlas I use "3A333A33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver) extender V2.11).rdf" dated Dec 31,2010. It's from RDF distribution 1.32.

I didn't get to Alpha 28 yet.