Page 1 of 1
Can a device upgrade be used in a keymove?
Posted: Tue Jan 16, 2018 3:20 pm
by csete
Last summer, I worked with everyone here to create the RDF for the Potenza remote and was able to do a good bit of tweaking of my remotes using RemoteMaster. I'm on to my next bit of tweaking today.
I have a super cheap HDMI (3x1) switch that I'd like to control easily with my remote. I learned the buttons from the provided (similarly cheap) remote and found that it uses standard NEC1 protocol. Using RemoteMaster, I converted those learned buttons to a device upgrade and set that on to the VCR button. I can use the buttons when in the VCR device mode to control the switch. What I'd like to do is use those keys in a keymove from within STB mode. In this case I was using the PIP keys on the remote. However, they don't appear to be doing anything in this case.
Is it possible to do what I'm attempting? If so, does anyone have thoughts on what I might be doing wrong?
Thanks,
Craig
Posted: Tue Jan 16, 2018 9:23 pm
by The Robman
Yes you can. No idea what you're doing wrong as I can't see what you're doing.
Posted: Wed Jan 17, 2018 7:12 am
by csete
Would it help if I posted my RMDU file?
Posted: Wed Jan 17, 2018 7:55 am
by The Robman
Lol, yeah!
Posted: Wed Jan 17, 2018 8:01 am
by csete
Sorry.. meant to say my RMIR file. I just put it into the diagnostics area at
http://www.hifi-remote.com/forums/dload ... e_id=25070
Posted: Wed Jan 17, 2018 10:03 am
by The Robman
So what am I looking at here? I assume the upgrade in question is DVD/2000, right? But looking at the keymove section, I don't see any keymoves that use DVD/2000. I do so several that use Audio/2000, even though there isn't an upgrade called that in the remote.
So, let's back up a step, how did you create these keymoves?
Also, I notice that your DVD/2000 upgrade shows up as using -1 as the sub-device, how did that happen? You should delete that and leave the sub-device blank.
Posted: Wed Jan 17, 2018 10:34 am
by csete
Thanks for taking a look Rob. You are correct about what upgrade I'm (trying to) use.
In terms of the sub device, I didn't change that, so it must have been created that way? Not sure why that would have happened, but I can tweak it as you suggest. In terms of the keymoves, I know that I selected the correct device type when I added the keymove. RemoteMaster bug maybe? I just validated that while I'm selecting DVD/2000 in the New Keymove dialog, that it always ends up as Audio/2000 in the keymove table. It sounds like that is the likely culprit with the keymove not working, although I have no idea how to work around that issue?
Thanks for any insights.
Posted: Wed Jan 17, 2018 12:36 pm
by The Robman
Not being able to watch over your shoulder, I can't see what you're doing, but I just changed all the keymoves to use DVD/2000 rather than Audio/2000 so see if this works.
http://www.hifi-remote.com/forums/dload ... e_id=25071
Posted: Wed Jan 17, 2018 12:49 pm
by mathdon
I will look into whether there is a bug in RMIR, but I suggest that you edit the RDF so that the Device Types and Device Buttons sections read:
Code: Select all
[DeviceTypes]
Cable = 0,0
TV = 1,1
Audio = 2,2
DVD = 3,3
DVD = 3,3
Cable = 0,0
Cable = 0,0
Cable = 0,0
[DeviceButtons]
STB=$09 0
TV=$01 0
AUD=$11 0
DVD=$0A 0
VCR=$12 0
dev6=$40 0
dev7=$41 0
dev8=$42 0
You will see I've exchanged the order of Audio and DVD in both lists. (Leave the DeviceTypeAliases section unchanged).
If you then edit your keymoves and select the DVD device type, it now remains as DVD in the Key Moves table.
Posted: Wed Jan 17, 2018 2:27 pm
by csete
mathdon wrote:I will look into whether there is a bug in RMIR, but I suggest that you edit the RDF so that the Device Types and Device Buttons sections read:
Code: Select all
[DeviceTypes]
Cable = 0,0
TV = 1,1
Audio = 2,2
DVD = 3,3
DVD = 3,3
Cable = 0,0
Cable = 0,0
Cable = 0,0
[DeviceButtons]
STB=$09 0
TV=$01 0
AUD=$11 0
DVD=$0A 0
VCR=$12 0
dev6=$40 0
dev7=$41 0
dev8=$42 0
You will see I've exchanged the order of Audio and DVD in both lists. (Leave the DeviceTypeAliases section unchanged).
If you then edit your keymoves and select the DVD device type, it now remains as DVD in the Key Moves table.
With this change to the RDF and updates to the keymoves, it works. That's awesome!
I don't believe this particular RDF (351601 (Potenza BC4).rdf) is currently "official", but it would probably be good to get this change in place for anyone else that may end up needing the RDF. What is the best way to go about that?
Posted: Thu Jan 18, 2018 8:49 am
by mathdon
csete wrote:I don't believe this particular RDF (351601 (Potenza BC4).rdf) is currently "official", but it would probably be good to get this change in place for anyone else that may end up needing the RDF. What is the best way to go about that?
On further investigation I find that there is a bug in RMIR, and that the existing RDF works when this bug is fixed. However, I will edit the RDF that is posted, and will add it to the official ones for the next build of RMIR that will fix the bug.
For those interested, here is more about the bug. It crept in in 2013 with the early work on XSight remotes and depends on the ordering of the entries in the [DeviceTypes] section of the RDF. These entries have one or two numeric parameters. The second parameter, when present, is the Device Type Number. For a particular remote, the values for this parameter will be consecutive numbers starting from 0. They may not be in numerical order and values may be repeated. The bug arises when the
first occurrences of each value are not in numerical order. So 0,1,2,1,3,2 is OK but 0,1,3,1,2,3 causes the bug. For the Potenza RDF the order is 0,1,3,2,3,0,0,0 so causing the bug. My fix changed this to 0,1,2,3,3,0,0,0 which is OK. The parsing of this RDF section had to be changed when XSight support was added, as it doesn't use numbers like this. Instead it uses letters to label device types, and the bug slipped in at that time.
The reason it has gone un-noticed for such a long time is that virtually all RDFs have an ordering in the [DeviceTypes] section that does not cause the bug to show. But I will fix the bug for the next build.
Edit: I have now updated the RDF
posted here with this fix.