RemoteMaster/RMIR v2.00-preview8 is now available

gfb107 · Post by **gfb107** » Wed Sep 15, 2010 6:12 am

RemoteMaster.v2.00-preview8.zip

Thanks to Graham and Vicky for all the hard work.

This should be the last preview before the general release of v2.00.

Changes since preview 7:

Check EEPROM size against RDF when importing .ir file (Graham)
Use Fixed Data as a matching criterion when downloading or importing a .ir file (Graham)
Ask whether to replace fixed data when there is a mismatch with RDF (Graham)
Fix bug that made an empty RDF [FixedData] section cause an exception (Graham)
Treat tab character as white space when parsing hex string (Graham)
Prevent NullPointerException if a manual protocol has no code for the processor concerned (Graham)
Recognise processor type S3F8 in heading of imported manual protocol (Graham)
Set PID from heading when importing manual protocol (Graham)
Update device parameter label when parameter name is edited (Graham)
Save unassigned manual protocols, ie those shown on Protocols tab, in .rmir file (Graham)
Edit a Manual Protocol by double clicking any of PID, Variant or Protocol columns of Devices tab (Graham)
Fix bug in handling of entries in RDF [DeviceTypes] section when a DevTypeNum value is given with no high byte (Graham)
Fix bug that prevented keymoves being updated in buffer when a new device upgrade was assigned to a device button in answer to the prompt (Graham)
Fix bug with raw data of keymoves when AdvCodeFormat=EFC (Graham)
Prevent multiple fixed data prompts and prevent any appearing when opening a remote with New (Graham)
Make deleting a manual protocol from the Protocols tab delete it also from ProtocolManager (Graham)
Prevent special function key moves being interpreted as EFCs when AdvCodeFormat=EFC (Graham)
Enable conversion between old and new S3C80 codes in both directions and ensure it occurs only when necessary (Graham)
In Manual Settings dialog, trim string before testing for "End" token, as trailing spaces were causing NumberFormatException (Graham)
Correct the maximum value of the Duration spinner for LDKP Special Protocol, changing it from 255 to 15 (Graham)
When importing a .ir file with protocol upgrades not used by device upgrades, add them to ProtocolManager as manual protocols (Graham)
Make ProtocolManager.findNearestProtocol check against Old Names as a final search (Graham)
Initial support for custom executors for known protocols, when parsing E2 image (Greg)
Add editable display of raw signal to Learned Signals Dialog and provide New facility (Graham)
Correct various matters to do with restrictions on allowed button bindings (Graham)
Correct bug that prevented attempts at raw download failing with a null pointer exception (Graham)
Handle remotes with a signature of fewer than 8 characters (Graham)
Handle special case of data format in remotes with empty upgrade section (Graham)
Circumvent a bug in jp1parallel.dll concerning uninitialized variables (Graham)
Key Moves tab: show attached key moves using background color (light gray, dark gray when selected) (Greg)
Raw Data tab: Show modified bytes in bold only (no more red) (Greg)
Devices tab: Adjust column widths (Greg)
Handle multiple protocol upgrades with same pid, which occurs even though the remote can only access the first one (Graham)
Because of the possibility of repeated pids, add name column to Protocols tab (Graham)
If deleting a device upgrade would delete corresponding protocol upgrade, ask for confirmation (Graham)
If changing the protocol of a device upgrade would delete a protocol upgrade, add that upgrade to Protocols tab (Graham)
Prevent change of pid when editing protocol upgrade but not when cloning it (Graham)
Fix bug in opening .ir file that has device combiner as a protocol upgrade (Graham)
When downloading or opening a file, clear ProtocolManager of custom code and added protocols specific to previous configuration (Graham)
When migrating key moves, avoid basing function names on keymove notes as notes such as names of other keys can cause errors (Graham)
Add an Edit Protocol button to the Devices tab (Graham)
Enable all protocols to be edited, adding/editing/removing custom code as required (Graham)
When editing a device upgrade, recognize and use any protocol present that will be treated by the remote as custom code (Graham)
Handle the case of device upgrades where the protocol is missing, treating it as a form of custom code but marked with '-' rather than '*' (Graham)
Correct two places in protocols.ini where "VariantName" had a space between the two words (Graham)
Update JP1 USB library to v0.03 (Greg)
Correct bug causing Code Selector to malfunction after a change of remote (Graham)
Correct handling of derived protocols when loaded from a .rmir file (Graham)
Handle an issue with device types that can be caused by a malformed [DeviceTypes] section in RDF (Graham)

Discussion of preview 8 begins here

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

RemoteMaster.v2.00-preview7.zip

Changes since preview 6:

Add Detach button and context menu item to Key Moves tab, to detach keymoves what are associated to device upgrades. Supports multiple selection (Greg)
Add installed upgrade selector to keymove editor, for upgrades that aren't assigned to a device button (Greg)
Add * after PID in Device tab to indicate a protocol upgrade will be installed with the device upgrade. (Greg)
Fixes for EFC5 handling of single-byte functions (Graham/Greg)
Fix bug to allow entry of Hex data in Key Move Dialog (Graham)
When decoding an E2image, don't associate keymoves to a device upgrade when the key is in the button map. (Greg)

Post by **vickyg2003** » Wed Sep 15, 2010 8:19 am

I looked at the keymoves on the 10820 and they look good. I'm getting what I expect in the rawdata on all types of remotes

I also ran on my elusive error, where the setup code appears to be on the setup code screen, but no keymoves show up, and when you flip back to the setup screen the setup is no longer associated with the key. I immediately closed my rmir session and here is the error log.

http://www.hifi-remote.com/forums/dload ... le_id=8952

Its obviously going to be an error you're going to be chasing for a long time, because I went back in and tried to recreate it and can't for the life of me get it to happen again.

Capn Trips · Post by **Capn Trips** » Wed Sep 15, 2010 6:11 pm

A brief foray into Preview 7 looks very promising.

I like the "detach" option on Keymoves, although that single word may not be sufficiently illustrative to the "typical" user. Perhaps a hover-help explaining that this would detach the keymove from being associated with an upgrade?

I see also that a Keymove in an IR file that COULD be made into a function mapped within a device upgrade is now retained as a keymove, but a "detached" one - which is OK by me, although having certain keymoves on a device displayed in a physically distant location from others, ... well I'd prefer to have the "detached" and "attached" Keymoves for a single device be adjacent to one another. Is there any way to allow re-ordering of the "attached" keymoves with the "detached"?

Also, is there a way to UNDO the "detach" operation?

Next, the upgrade memory calculation on my test file suddenly got all wacky. In IR, it displays memory remaining of 6 bytes Keymove/Macro and 0 bytes Upgrade, while in RMIR it's 6 (OK) and 222(!) respectively. Somewhere in there it has forgotten how to calculate the upgrade memory usage, 'cause I got a buttload of upgrades in there and zero memory.

..and on the memory usage note, could a narrow display column be added to each page indicating how many bytes each Keymove, Macro, SP keymove, and Upgrade consumes? I know that in the Keymoves Tab it's pretty easy to see (in the Raw Data column) but on the others it's not intuitive, and for Upgrades, you have to open the upgrade and navigate over to the output Tab to figure out how much memory the entire thing is consuming. (I like the asterisk indicating that there IS a Protocol Upgrade, though! perhaps in lieu of the asterisk a parenthetical number indicating the memory usage of the protocol upgrade)

Finally, what determines whether an entry on the Raw Data page is red or not? When I open that file, a whole lot of the Raw Data is red, although I have not changed nor edited ANYTHING. Not sure I understand what it's telling me.

LOTS of exciting stuff getting crammed into RMIR in recent days, and I thank (and commend) all of you guys for pressing forward with this awesome tool! I just lament that the next generation of UEIC JP4(?) remotes may, apparently, be either unhackable or incompatible with these great tools.

Capn Trips · Post by **Capn Trips** » Wed Sep 15, 2010 6:15 pm

OK, so the SECOND time I opened that test file, the Memory calculations were different, giving me a 6 and a 5, respectively, so I guess that was a one-off glitch, as Vicky already explained away the 5 bytes difference being due to RMIR using an updated protocol upgrade in one of my device upgrades to the one I had available back then.

The question about displaying memory usage and the coloring on the Raw Data Tab still applies, however.

Thanks

gfb107 · Post by **gfb107** » Wed Sep 15, 2010 7:45 pm

Capn Trips wrote:A brief foray into Preview 7 looks very promising.

I like the "detach" option on Keymoves, although that single word may not be sufficiently illustrative to the "typical" user. Perhaps a hover-help explaining that this would detach the keymove from being associated with an upgrade?

I meant to do that, but I did it incorrectly. That will be fixed in the next preview. I used the text "Detach from upgrade", but am open to other suggestions.

I see also that a Keymove in an IR file that COULD be made into a function mapped within a device upgrade is now retained as a keymove, but a "detached" one - which is OK by me, although having certain keymoves on a device displayed in a physically distant location from others, ... well I'd prefer to have the "detached" and "attached" Keymoves for a single device be adjacent to one another.

Until we have a way, within a device upgrade, to force a particular assignment to generate a keymove, this is the only way to keep the keymove from being converted into a button-mapped function. You told us you did not want that.

Is there any way to allow re-ordering of the "attached" keymoves with the "detached"?

Not really. You can sort on Device Button or maybe Setup Code to reorder the view, but that is only a temporary display thing, it doesn't change the actual order.

Also, is there a way to UNDO the "detach" operation?

Not yet. I expect to add an "Attach" button and context menu item at some point. That isn't a true UNDO (which we don't have anywhere in RM/RMIR), but it will give you a way to do that.

I've been thinking about it a bit, and it may also be possible to enable some of the other actions for attached key moves. I'm pretty sure we could do delete, and even changing the bound key. Possibly even changing the assigned function. Anything more would require detaching the keymove.

Next, the upgrade memory calculation on my test file suddenly got all wacky. In IR, it displays memory remaining of 6 bytes Keymove/Macro and 0 bytes Upgrade, while in RMIR it's 6 (OK) and 222(!) respectively. Somewhere in there it has forgotten how to calculate the upgrade memory usage, 'cause I got a buttload of upgrades in there and zero memory.

I hope you figure out how you got this to happen, so we can fix it.

..and on the memory usage note, could a narrow display column be added to each page indicating how many bytes each Keymove, Macro, SP keymove, and Upgrade consumes? I know that in the Keymoves Tab it's pretty easy to see (in the Raw Data column) but on the others it's not intuitive, and for Upgrades, you have to open the upgrade and navigate over to the output Tab to figure out how much memory the entire thing is consuming. (I like the asterisk indicating that there IS a Protocol Upgrade, though! perhaps in lieu of the asterisk a parenthetical number indicating the memory usage of the protocol upgrade)

Adding a Size column to every tab would be relatively painless way to add some semblance of memory management capabilities to RMIR. I definitely would want to be able to turn display of that column on and off. If we do this, I think it would be reasonable to turn the * after installed protocols into (size). For clarification, would the Size column on the Device tab include the size of the protocols upgrade (maybe not 'cause that would be visible in the PID(Size) column)? Would it include the size of all attached keymoves (maybe not because those would be shown individually on the Key Moves tab)?

Finally, what determines whether an entry on the Raw Data page is red or not? When I open that file, a whole lot of the Raw Data is red, although I have not changed nor edited ANYTHING. Not sure I understand what it's telling me.

It is showing you which bytes in the Raw Data have changed. Some of those changes are a direct result of RMIR using a different, smaller pause protocol. That would shift things around within the upgrade area. Most of the changes are because RMIR works very differently than IR.

As I explained before, RMIR doesn't work directly in an E2 image - it decodes the E2 image into lists of macros, keymoves, upgrades, etc.

When there is a need for the E2 image (viewing on the Raw Data tab, for example), it writes those lists out into the E2 image. This almost certainly is will result in things being ordered differently than in your IR file.

For the advanced function section, it uses this order:

Keymoves
Attached Keymoves
Special Function Keymoves
MultiMacros
Macros
Special Function Macros (for native DSM)
FavKey (if the remote uses segregated FavKey)
TimedMacros (if the remote supports them)

Capn Trips · Post by **Capn Trips** » Wed Sep 15, 2010 9:59 pm

gfb107 wrote:
Capn Trips wrote:I see also that a Keymove in an IR file that COULD be made into a function mapped within a device upgrade is now retained as a keymove, but a "detached" one - which is OK by me, although having certain keymoves on a device displayed in a physically distant location from others, ... well I'd prefer to have the "detached" and "attached" Keymoves for a single device be adjacent to one another.
Until we have a way, within a device upgrade, to force a particular assignment to generate a keymove, this is the only way to keep the keymove from being converted into a button-mapped function. You told us you did not want that.

Absolutely. I'm happy with the way it is now. Thanks.

gfb107 wrote:
Is there any way to allow re-ordering of the "attached" keymoves with the "detached"?
Not really. You can sort on Device Button or maybe Setup Code to reorder the view, but that is only a temporary display thing, it doesn't change the actual order.

Oh right. That's sufficient for me - just to be able to see them together when I want to.

But now that you bring it up, I have always been frustrated that there is no easy way to re-order functions in RM's Functions Tab, aside from dragging each one individually. Is there a way to allow one to re-order them after a sort (I like to usually have mine sorted in OBC order, but they always revert to the order they were entered, and it takes forever to re-order them manually.)

gfb107 wrote:
Also, is there a way to UNDO the "detach" operation?
Not yet. I expect to add an "Attach" button and context menu item at some point. That isn't a true UNDO (which we don't have anywhere in RM/RMIR), but it will give you a way to do that.

I've been thinking about it a bit, and it may also be possible to enable some of the other actions for attached key moves. I'm pretty sure we could do delete, and even changing the bound key. Possibly even changing the assigned function. Anything more would require detaching the keymove.

Cool.

gfb107 wrote:
..and on the memory usage note, could a narrow display column be added to each page indicating how many bytes each Keymove, Macro, SP keymove, and Upgrade consumes? I know that in the Keymoves Tab it's pretty easy to see (in the Raw Data column) but on the others it's not intuitive, and for Upgrades, you have to open the upgrade and navigate over to the output Tab to figure out how much memory the entire thing is consuming. (I like the asterisk indicating that there IS a Protocol Upgrade, though! perhaps in lieu of the asterisk a parenthetical number indicating the memory usage of the protocol upgrade)
Adding a Size column to every tab would be relatively painless way to add some semblance of memory management capabilities to RMIR. I definitely would want to be able to turn display of that column on and off. If we do this, I think it would be reasonable to turn the * after installed protocols into (size). For clarification, would the Size column on the Device tab include the size of the protocols upgrade (maybe not 'cause that would be visible in the PID(Size) column)? Would it include the size of all attached keymoves (maybe not because those would be shown individually on the Key Moves tab)?

Well, I don't think about the actual details, I leave that to YOU. But I agree that it should not be a default display, but a selectable one. For Device upgrades, I would have a column for just the Device upgrade memory usage, and use the parenthetical adjacent to the PID for the protocol memory usage (if any). That would also be a de facto indication of whether the upgrade uses a built-in protocol. Keymoves not necessary for the Device display since they're already on the keymove Tab. If one wants the TOTAL cost of the upgrade (including Keymoves) that's still on the output Tab in RM.

gfb107 wrote:
Finally, what determines whether an entry on the Raw Data page is red or not? When I open that file, a whole lot of the Raw Data is red, although I have not changed nor edited ANYTHING. Not sure I understand what it's telling me.
It is showing you which bytes in the Raw Data have changed. Some of those changes are a direct result of RMIR using a different, smaller pause protocol. That would shift things around within the upgrade area. Most of the changes are because RMIR works very differently than IR.

Okey-dokey.

Capn Trips · Post by **Capn Trips** » Mon Sep 20, 2010 8:48 am

One additional "oh-by-the-way".

Can you add to RMIR the (perhaps as a selectable advanced option) capability for the user to "approve" or "reject" automatic protocol changes?

In my test file above, upon opening the IR file in RMIR, the pause protocol is automatically replaced leaving the user unwitting of this change. I understand that once one is no longer using IR files and is 100% converted to RMIR, this should not be an issue, but...see below.

In the "automatic functions" department, how would RMIR handle this situation if it is DOWNLOADED from a remote? Would it automatically change protocols, device upgrades, what-have-you?

Many Cable operator remotes come with device and protocol upgrades pre-installed. Occasionally, these upgrades duplicate built-in set-up codes and/or protocols. Upon initial download from such a remote, will RMIR start making automatic changes?

gfb107 · Post by **gfb107** » Mon Sep 20, 2010 8:51 am

We are working on making sure RMIR preserves that actual installed executor.

Post by **vickyg2003** » Mon Sep 20, 2010 10:45 am

I've used the preview 7, and can now open a new Comcast 1067A and can download from the remote just fine.

So I thought maybe I could open my simple multiplex with keymoves example, but that one still bombs out. This one uses a different RDF, the extender RDF. I can see an error in the rmerror log, about the array being out of bounds.

I don't have an extender installed on my bench remote, but I could if you think its an RDF problem, but I think its a multiplexing problem.

Post by **vickyg2003** » Mon Sep 20, 2010 2:30 pm

Took a closer look at Preview 7.

First I have an issue with the toolbar. Most of the options are inactive, including the code selector. File New doesn't activate anything on my toolbar. This worked as expected in earlier previews.

Second I tried A file->New, and chose the JP1.2 Comcast 1067 (cs300109),
I then go to the device upgrade sheet and open this km sheet
http://www.hifi-remote.com/forums/dload ... le_id=8971

I am not asked if I want to assign this device to a button, even though I know its loaded with keymoves. I switch over to the General tab, and associate the button to the Aux button by hand since the code selector is not active. I see all the keymoves on the keymove tab, but the indicator bars show no keymoves no upgrades and none are being shown in the E2 area.

I have some download issues with keymoves too, but I don't think you want to see those until we can build a remote from scratch.

PS, when adding keymoves to device keymoves sheet is no longer being refreshed, and the data in the raw code column is nonsensical and I can't find what I'm seeing on the rawdata tab. The protocol in question is Pid 00 27:new

Post by **vickyg2003** » Mon Sep 20, 2010 3:03 pm

SaveAS

SaveAs keeps adding .RMIR to the original file.

If you do saveAs and you choose an IR file, nothing gets saved, however if you save it first and then do a saveAs and the file appears with .rmir.rmir after it, if you choose save as .ir, a rmir.ir file is created that is an RMIR file.

Edit:

It appears that nearly everything that got fixed is broken again. I redownloaded the file to make sure I didn't have some corruption. My keymove screens and device screens are not updating until you navigate away from them. Some of the new features are there, but its almost like they were applied to preview 3.

Post by **vickyg2003** » Mon Sep 20, 2010 5:33 pm

Apparently all my problems are Comcast related. I just tried all the things that were going wrong, and everything looks great on other remotes.

So what is the problem with the RDF.

I used other RDF's and the weird updating is gone.

Problem with the 1994,10820n going from the file new, and then loading this upgrade, the keymoves are not making it to the e2 area, when you attach it to the key. You need to detach and then reattach to get the e2 area to populate with the keymove data. However the keymoves look a heck of a lot better than they did for the Comcast remote.

http://www.hifi-remote.com/forums/dload ... le_id=8971

Post by **vickyg2003** » Tue Sep 21, 2010 2:05 pm

Taking a closer look at keymoves, I look at the encoded keymoves in the output window of KM and RM and trying to figure out how these relate to the hex in IR and RMIR and the rawdata in the E2 area.

this is what IR says
SHIFT-Menu DVD AUX 2002 $58 $59 02204 Top Menu

The keymove in the output window looks like this.
¦8C F0 04 27 D2 08 9C«Top Menu»

RMIR shows
RAW 27 D2 58 59 HEX 58 59

I think raw data should be
27 D2 08 9C HEX $58, $59

089C = 02204 5 DIGIT EFC THAT LEADS TO $58, $59

This 089C is what IR has in the E2 area, while RMIR is SHOWING 5859 in the e2 area.

Post by **vickyg2003** » Tue Sep 21, 2010 4:13 pm

Sometimes when you add an upgrade the keymoves don't make it into the e2 area.

http://www.hifi-remote.com/forums/dload ... le_id=8977

If you upload an image like this, the remote will not get any keymoves either, but if you save it and reopen it the e2 area is populated. (Seen in red)

How far is this going to be taken?

Is the hex and protocols subject to change whenever you open an RMIR file?

Post by **vickyg2003** » Thu Sep 23, 2010 2:49 pm

Protocol bug when things are added out of order

Created a new urc-7800

added my sony device

http://www.hifi-remote.com/forums/dload ... le_id=8971

added this protocol to check to see how RMIR was processing data
Upgrade protocol 0 = 00 27 (S3C8) Sony Combo (12/15/20) (TEST )
3A 8A 42 8B 15 F8 15 05 07 02 58 01 18 01 2C 01
18 57 D0 04 B0 01 18 08 03 08 76 07 01 EB 17 76
08 01 6B 0F E6 28 F9 E6 12 08 08 08 E0 C0 56 C0
03 09 01 E6 24 06 8D 01 36
End

Looks good.

However if I start by adding the custom protocol, and then adding the device, the protocols tab goes blank, E2 is still showing the 06.
If I add another device that uses this protocol (0027), the E2 no longer shows the custom protocol.