Page 51 of 59
Posted: Tue Jan 20, 2015 3:24 pm
by ElizabethD
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?
Posted: Tue Jan 20, 2015 6:19 pm
by vickyg2003
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.
Posted: Wed Jan 21, 2015 9:17 pm
by ElizabethD
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.
Posted: Thu Jan 22, 2015 3:03 am
by mathdon
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.
Posted: Thu Jan 22, 2015 8:48 am
by gfb107
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.
Posted: Thu Jan 22, 2015 1:08 pm
by ElizabethD
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.
Posted: Thu Jan 22, 2015 3:59 pm
by vickyg2003
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.
Posted: Thu Jan 22, 2015 9:25 pm
by ElizabethD
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.
Posted: Fri Jan 23, 2015 6:44 am
by vickyg2003
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?
Posted: Fri Jan 23, 2015 7:37 am
by vickyg2003
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.
Posted: Fri Jan 23, 2015 12:44 pm
by mathdon
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.
Posted: Fri Jan 23, 2015 1:39 pm
by xnappo
That is real. It was more to do with RDF versions not matching extender versions if I recall.
Posted: Fri Jan 23, 2015 2:42 pm
by vickyg2003
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.
Posted: Fri Jan 23, 2015 3:15 pm
by ElizabethD
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.
Posted: Fri Jan 23, 2015 4:21 pm
by ElizabethD
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.