RMIR problem(s) loading pause upgrade for Charter URC-1060BC

[jeajea]

RMIR problem(s) loading pause upgrade for Charter URC-1060BC2(3)
RMIR v2.03 Alpha 28 build 13 (and 11)
Windows 7 PRO 64bit
Java 8 update 31 (and 25)
RMIR identifies the remote as URC-1060BC2
Sticker in battery compartment indicates
URC-1060BC3-0780-002-R

Code: Select all

Code.MAXQ610=78 B4 01 04 00 00 D0 07 00 80 08 5A 00 00 00 58 FC D0 00

Added to [Pause Protocol (Special)] in protocols.ini

I did a 981 reset on the remote before added the upgrade

When I added the upgrade as device DVD the key moves show up on the
keymove tab but the protocol isn’t visible on protocol tab. At this point the
assigned DVD keys launch the pauses. However, if you use a keymove to
assign the 9.5 sec pause functions to TV REC it doesn’t launch the pause.
In build 11 the DVD keys did not launch the pause.

Next I deleted the pause upgrade without deleting the protocol which made
the pause protocol visible on the pause tab. I re-added the upgrade as
device DVD. The pause was still visible. When I pressed TV REC I got a
pause of about 26 seconds instead of 9.5 seconds

My upgrade and RMIR files


https://www.hifi-remote.com/forums/dload ... e_id=13200

[mdavej]

Can you also post a raw download?

[jeajea]

the raw download (has three other device upgrades

https://www.hifi-remote.com/forums/dload ... e_id=13201

[mathdon]

Nothing you have described suggests to me a problem with the RMIR program.

RMIR identifies the remote as URC-1060BC2
Sticker in battery compartment indicates
URC-1060BC3-0780-002-R

I am aware of this issue of identification. In this post I wrote

Dave (3FG), I am somewhat confused by the version numbers for the Charter remote. The RDF repository contained one called "202608 (Charter OCAP C4000 URC-1060BC2).rdf". These recent posts speak of a signature 202608 but version BC3. I have assumed these are the same remote, and have updated that existing RDF to use the new support in RMIR for segment type 0x0E. I hope this is OK. The RMIR upgrade file contains this revised RDF, also your recent one for URC-8820BC1.3, as well as the new RMIR jar file.

It needs someone familiar with the versions of this remote to sort this out. I presume there really is a BC2 version so would not want to re-name the existing RDF to BC3. What we really need are RDFs for both versions and information on how the two versions of the remote differ from one another.

When I added the upgrade as device DVD the key moves show up on the keymove tab but the protocol isn’t visible on protocol tab.

This is correct behaviour. In this remote it is possible to have a protocol upgrade that is not used by any device upgrade. This was also the case in JP1.3 and earlier remotes but this is the first JP2 remote we have seen with this possibility. The Protocols tab is there to show these unused protocol upgrades and so this tab is absent for remotes without this possibility. Protocol upgrades used by device upgrades are shown in the Devices tab, from which they can be viewed and edited.

However, if you use a keymove to assign the 9.5 sec pause functions to TV REC it doesn’t launch the pause.

On many remotes, the Record key has to be pressed twice to perform its action. This is a safety measure to prevent accidental recording.

Next I deleted the pause upgrade without deleting the protocol which made the pause protocol visible on the pause tab.

Again, correct behaviour. The protocol is now not used by any device upgrade, so does show on the Protocols tab.

I re-added the upgrade as device DVD. The pause was still visible.

Re-adding the upgrade adds a second copy of the protocol. The copy used is accessible through the Devices tab, the unused copy through the Protocols tab.

When I pressed TV REC I got a pause of about 26 seconds instead of 9.5 seconds

That seems to be a problem with the Pause (Special) protocol, not with RMIR.

[ruidosobruce]

It needs someone familiar with the versions of this remote to sort this out. I presume there really is a BC2 version so would not want to re-name the existing RDF to BC3.

I have both BC2 and BC3 versions of the URC-1060 remote. They seem very similar: MaxQ610 Processor, Signature 202608, 5.5k memory area.

Just being careful, for my BC3 I had made a duplicate of the BC2 RDF and renamed the copy URC-1060BC3 and put changes I was making in that file.

I would be happy to do any other comparison tests of these two remotes.

[jeajea]

Thanks for explaining how things actually work.
My choice of using the record button for testing was bad.
My only remaining issue is pause durations that are correct when
assigned to a device slot become 25+ seconds when a key move is use
to assign the function to a button on a different device.

It appears to be using a duration value of 255 or maybe 0.

Is this a known key move limitation?

[3FG]

BC2 versus BC3: As near as I can tell, the only difference in these remotes is the sticker in the battery compartment. They have the same signature, and separate RDF files would contain identical information except for the name. I'm quite confident that internally the two remotes are identical. From my point of view I would rather rename the RDF to 202608 (Charter OCAP C4000 URC-1060BC2_BC3) (or whatever doesn't break the RDF naming rules) and not oblige users to make a meaningless selection of BC2 or BC3.

I'm also comfortable that the Pause executor works, at least on an Atlas 1056B03. Jim, as I mentioned in your other thread, the next version of protocols.ini will handle the duration in units of 1/16th of a second, so the maximum pause time will be about 16 seconds. Here's the new entry:

Code: Select all

Code.MAXQ610=78 FF 01 04 00 00 E8 03 00 80 08 5A 00 00 00 58 FC D0 00

I recommend you change to this entry now so you don't get surprised later.

I found that on the Atlas, assigning the Pause Duration to a normal button works, and assigning it to a shifted button also works provided the shifted button was called from a macro. However, manually pressing the button after pressing Setup does not result in a pause. Pause works in this way regardless of which devices and device types are invoked.

RMIR confuses me while working with Pause. Starting from a reset remote, if I add a Pause device upgrade, assigning the functions to ordinary buttons, then RMIR makes this assignment and also automatically adds keymoves for each assigned function. After uploading to the remote, the Pause function works. If this Pause upgrade is deleted in RMIR, the keymoves are also deleted. The unexpected behavior happens if I download from the remote, and now delete the Pause upgrade. RMIR does not delete the keymoves. With RMIR in this state, adding a Pause upgrade and assigning the buttons does not add keymoves, nor does it change the values in the existing keymoves if some of the Durations were changed. Also, if now the bound key is changed, it may not be reflected in the Segment Editor. I'm not familiar with Pause, so perhaps this is normal, but it seems odd to me.

[mathdon]

From my point of view I would rather rename the RDF to 202608 (Charter OCAP C4000 URC-1060BC2_BC3) (or whatever doesn't break the RDF naming rules) and not oblige users to make a meaningless selection of BC2 or BC3.

The underscore has a special meaning in RDF filenames and this form would be expanded into a (meaningless) choice. Most other separators are illegal in filenames, so I think the possibilities are 202608 (Charter OCAP C4000 URC-1060BC2BC3) or 202608 (Charter OCAP C4000 URC-1060BC2-BC3), neither of which is ideal.

I would prefer to leave any name change until we have the automatic updating in place that Marcin is working on. The problem is that I can't make an RMIR update file that deletes an RDF, not until SVN support is in place in RMIR updating, and it would be confusing to have two RDFs for this remote, one with the old name and one with the new.

The alternative is to start Alpha 29 (or a Beta version) and have a full distribution only, and to start the update files again from that. I have already wondered if the time is ripe for that, as there have been a lot of changes in the numerous builds of Alpha 28, but there are a few more things I want to do before moving to Alpha 29 or Beta 1.

I think the unexpected behaviour with the Pause protocol is related to the general behaviour of RMIR with device upgrades. RMIR has the concept of keymoves being "attached" to an upgrade. These are function assignments defined in the upgrade that are assigned to buttons not in the relevant button map for the remote. These assignments create keymoves in the remote that are specified in the upgrade, and so which are deleted when the upgrade is deleted. In the Key Moves tab of RMIR they have a gray background. Such a keymove can be detached from the upgrade (with the Detach button) and its gray background becomes white. It will now not be deleted when the upgrade is deleted. However, this is purely an RMIR concept. The remote makes no distinction between attached keymoves and any others, so on download from the remote they all appear as detached, and so will not be deleted when the upgrade is deleted.

I don't understand the oddities that happen when you then add another Pause upgrade, but I will try to look into it. I have never used the Pause (Special) protocol and know nothing about it, but the behaviour may again be something that applies to upgrades in general, in which case there may be something needing attention.

[3FG]

After thinking some more about the BC2/BC3 issue, I don't think we need to change anything. I'll compare this situation to Comcast remotes. The JP1.3 remote has signature 30393039 and our RDF file identifies these as URC-1067BX3. I have 4 of these remotes, all from 2009, but the battery compartment stickers say variously 1067BC3-0001-R, RC1475505/02MB, and RC1475505/03MB. Later, we saw "platinum" colored remotes with stickers which say 1167BC0-0001-R, and others which are RC1475505/04SB. There is also a RC1475507 series. BTW, the more recent cosmetically identical remotes are JP2 with signature 255602. Stickers include RC1475511/01B and 1067CBC4-0004-R.

The point is that the sticker probably tells us more about the manufacturing facility used to make the remote than the firmware. And mostly users don't even think about the sticker numbers. Perhaps the question about BC2/BC3 arose now because we have only had the ability to add upgrades for the last couple of weeks--from a JP1 standpoint, these are new remotes. One thing we can do easily is to change the Name field in the RDF from Name=URC-1060BC2 to Name=URC-1060BC2/BC3, so that a little investigation will reassure a user that the RDF is supposed to work with either BC2 or BC3.

The issue with the keymoves is not limited to Pause upgrades, and I think we should investigate to see if RMIR can be modified to add a check. I made an upgrade using the Dish IR protocol, and gave it setup code 2121. I assigned functions to shifted buttons and uploaded to the remote in two configurations: 1) setup code 2121 assigned to a device button and 2) 2121 not assigned to a device button. Then I downloaded from the remote and for case 1 changed the assignment from 2121 to a built in setup code. RMIR asked if I wanted to keep the keymoves (good!). For 2) I deleted the Dish upgrade--so setup code 2121 no longer existed, but RMIR said nothing about the now-orphaned keymoves. After uploading to the remote, the buttons associated with the orphaned keymoves do nothing.
So I think RMIR should check each time an upgrade is deleted to see if keymoves are orphaned, and ask the user if it is desired to keep the keymoves-- which the user may want to do if the purpose of deleting the upgrade was to replace it.

[ElizabethD]

3FG, Graham,
Just about Pause, in case my notes might be helpful and doesn't derail your Charter discussion:
Based on my JP1 remotes (see sig) my pause keymoves aren't deleted when the pause device is deleted because RMIR asks whether to retain the protocol and I say yes. I just tried it, since normally I leave it alone, so that I can try various numbers, which will be gone when pause device is zapped.
Perhaps I build differently. I don't assign any pauses to any buttons in the upgrade, so they are not in the grey area. I just make functions in the pause device for 1,2,3,4,5 seconds. Then I make a keymove in RMIR and select Function option and then the duration function.
(I've given up on various built-in pauses with their weird timings such as 2sec setting running for 20sec. I use the simple looping one from KM. It's really universal because doesn't need any JMP addresses so you can move it from remote to remote. Just change the PID to something like 01EB since RMIR hates duplicate PIDs. 2sec function will not be exactly 2sec - depends on remote speed exhausting its counters, but it's close.)

[jeajea]

To clarify my pause duration problem

If the pause upgrade is assigned to a device slot such as TV and buttons for that device are used (either assigned in the upgrade or by key move) the correct pause duration is used.

If you assign the pause to a button on a different device via key move the duration becomes maximum (255 or maybe 0) when that device and buttons are use.

If you change the setup code to a real TV type the duration becomes maximum (255 or maybe 0).

[jeajea]

I tried the same combinations on an Atlas 1056B01 and the pause durations were correct.

[mathdon]

I think RMIR should check each time an upgrade is deleted to see if keymoves are orphaned, and ask the user if it is desired to keep the keymoves

Please try Alpha 28 Build 14 to see if it now does what you want.

[mathdon]

One thing we can do easily is to change the Name field in the RDF from Name=URC-1060BC2 to Name=URC-1060BC2/BC3

I have changed the entry to

Code: Select all

Name=Charter OCAP C4000 URC-1060BC2 and URC-1060BC3

in the SVN and will include this revised RDF in the next build of RMIR.

[3FG]

Graham,
I tried out Build 15 with deleting a device upgrade which has keymoves. It does exactly what I had hoped. Thank you.