RemoteMaster v1.90 is now available

[gfb107]

I've built and released RemoteMaster v1.90

Available downloads are:

• RemoteMaster.v1.90.zip - (~1.6MB) Multi-platform Java program, works on Windows, Linux, etc..
  • Requires a Java 1.6 or newer runtime environment.
  • Please read and follow the installation instructions
• RemoteMaster_v1.90.exe - ( ~21.2MB) Windows standalone application
  • Compiled, packaged, and powered by Excelsior JET.
  • Note: You must follow steps 4 and 5 of the installation instructions

Changes for v1.90

• Fix bug in special protocol dialog for protocols that use the 2nd column of functions.
• Improvements for poorly learned/decoded IR signals
• Fix column widths and header height in learned signals
• Better error handling for unsupported versions of interface libraries/DLLs
• Add duration control to Dish Network Combo as a device parameter encoded in the protocol code.
• Show protocol code even when not required (when available)
• Make protocol code required when there's an encoded device parameter with a non-default value.
• RMIR: Add Edit button under device buttons on General tab to edit the device upgrade for the assigned setup code.
• RMIR: Update the jp12serial interface .dll/.so to version 0.11

Links:
The RemoteMaster project home page, now accepting donations.
RemoteMaster.v1.90.zip
RemoteMaster_v1.90.exe - See note below.
Change Log (also included in the ZIP file)
Readme.html (also included in the ZIP file)

Notes:

• The stand-alone Windows version is compiled and packaged with Excelsior JET.
• Don't forget to follow steps 4 and 5 of the installation instructions.

[mdavej]

Greg and Mike,

Would you add some additional info to the DirecTV protocol notes? Similar to the Panasonic protocol using a couple of different subdevice numbers, DirecTV uses several different device numbers now (used to use 4 different ones, now uses 8). HERE are the details.

Thanks

[The Robman]

Show protocol code even when not required (when available)

I don't think this is a good idea. While I like having the protocol code available, even when it's not required, simply displaying it in exactly the same way that the device upgrade is displayed I think can be misleading. I bet most newbies, and maybe a few old-timers, are going to start installing protocol upgrades that are not required.

In KM, when the protocol is not required, it's presented in white font so it's invisible to most people but you can still cut and paste it if you want to examine it (of course, you need to know that it's there, but that's kind of the point).

I think it would be better to have a checkbox or something that you can use to display the protocol code if you want to see it, and even then I'd like to see a message displayed saying that the protocol upgrade isn't required.

At the very least, please display something saying that the protocol upgrade is not required, preferably in non-black/non-red text to make it stand out and be different from the "required" message.

[gfb107]

mdavej, I'll be happy to update the notes for the DirecTV protocol as you like. If you don't mind writing up what you want to see in RM, I'll handle the rest.

[gfb107]

When the protocol code is required the title of the text area says

Upgrade Protocol Code *** REQUIRED ***

When it's not required, it just says

Upgrade Protocol Code

Making the text color the same as the background color when the code isn't required is simple enough.

OR I could add a 'Show code' check box (that would NOT be saved permanently) next to the Copy button to show the code. The checkbox would only be enabled when there is code available but not required.
That seems more user friendly, but it also clutters the interface with a feature that most users will never use.

[The Robman]

When I look at a simple upgrade in RM now, I see two blocks of code, one labeled "Device Upgrade Code" and another labeled "Protocol Upgrade Code", with both labels using black font. Both upgrades have the COPY button available.

If I wasn't already intimately familiar with this program, how would I know that I SHOULD copy the first block and should NOT copy the second block?

If I've never looked at an upgrade that did require a protocol upgrade, I might not know that the text turns red in that case.

I'd like to see the text read "Upgrade Protocol NOT Required" and the protocol code not be displayed. You could have a checkbox to display the code if you like, or you simply have an un-documented feature similar to the one in KM where the COPY button will copy the protocol even when it's not displayed.

The only people who are going to be interested in looking at protocol code when it's not required are experts who want to debug why it's not working properly, so I don't see the need to confuse the masses by displaying a protocol upgrade that isn't required.

[mdavej]

You could add the following. I'd like for Mike or Rob to bless off on the wording and whether it's descriptive enough or even belongs in the protocol notes at all.

Code: Select all

The Device Number selects between eight different receiver addresses:
Address 1 = Device Number 12
Address 2 = Device Number 13
Address 3 = Device Number 2
Address 4 = Device Number 3
Address 5 = Device Number 8
Address 6 = Device Number 9
Address 7 = Device Number 1
Address 8 = Device Number 0

The default Address is 1.

I'm not sure what to do about older upgrades that use manual settings. You can change the fixed data for different address, where the first nybble is the device number in hex. So if the fixed data was C3, where C = device 12, to change to address 2, make the fixed data D3, where D = device 13.

[Capn Trips]

I'd like to see the text read "Upgrade Protocol NOT Required" and the protocol code not be displayed. You could have a checkbox to display the code if you like, ....

... I don't see the need to confuse the masses by displaying a protocol upgrade that isn't required.

I agree with Rob's suggestion above.

I would also like to see a display of how much memory is required for a particular Device upgrade and/or Protocol upgrade and the associated keymoves, as is available in KM. This helps when one is trying optimize a configuration.

Digression follows: (Oh no! here he goes again on his Kaseikyo-SharpDVD rant!)

This is as good an opportunity as ever to revisit a topic I railed about a while ago, and that is to allow one in RMIR to selectively include or exclude protocol upgrades associated with device upgrades and allow "disassociation" of keymoves from their related device upgrades- perhaps by an advanced menu slection to activate a check box in the pop-up RM window launched from within RMIR, or something along those lines.

To refresh anyone's memory, it stemmed from the challenges of dealing with the Kaseikyo family of protocols. I do not recall whether it was the RDFs or RM or what, but the specific example was that RM was not correctly calculating/displaying the requirement for a protocol upgrade associated with the SharpDVD protocol. Originally, now fixed, I had this problem with the URC-8910/9910/HTPro but now it's happening again with my URC-1056 Atlas OCAP.

Background: The learned and decoded signals from a Sharp DVD OEM remote control always decode as Kaseikyo 170.90 Device 8:48. This can be replicated in RM or KM using the Kaseikyo protocol and entering all of the appropriate parameters, which will always require a protocol upgrade (to my knowledge, the base Kaseikyo protocol is not built-in to any JP1 remote).

The same upgrade can be built using the SharpDVD protocol, which IS built in to some UEIC remotes, and when one does so, for the 8910/9910/HTPro it correctly shows that no protocol upgrade is required, but for the Atlas OCAP URC-1056, a protocol upgrade is shown as required. That is incorrect, as the SharpDVD protocol IS resident in the OCAP. In this case, I have been copying and pasting the RM-generated Device upgrade into IR, and omitting the otherwise incorrectly-labelled as "Required" Protocol upgrade, and the device upgrade works fine, so apparently the Sharp DVD protocol IS resident in the OCAP remote.

I realize that this specific case should be highlighted so that someone can fix the RDF so that RM correctly identifies that the protocol upgrade is not required, but that is just ONE instance in which an advanced user may want to have some control over the inclusion ro exclusion of a protocol upgrade linked to a device upgrade. I won't revisit the entire discussion from here, but feel free to review it. Here and here and here.

[Capn Trips]

OK, I'll simplify my above post to make it digestible.

Feature requests for RM:

I'd like to see the text read "Upgrade Protocol NOT Required" and the protocol code not be displayed. You could have a checkbox to display the code if you like, ....

... I don't see the need to confuse the masses by displaying a protocol upgrade that isn't required.

I agree with Rob's suggestion above.

I would also like to see a display of how much memory is required for a particular Device upgrade and/or Protocol upgrade and the associated keymoves, as is available in KM. This helps when one is trying optimize a configuration.

Feature requests for RMIR:

(1) It would be useful to be able to "Disassociate" a Device upgrade from its Protocol upgrade (to allow independent manipulation of the protocol and protocol ID in RMIR); and/or
(2) to disassociate a device upgrade from its associated keymoves.

Perhaps this could be done via an advanced menu selection in the RM window that opens for editing in RMIR. This would prevent the beginner or casual user from inadvertently doing this, but would allow the advanced user the flexibility for troubleshooting and advanced setups.

I won't go into a list of various scenarios when this would be used, because this discussion has occurred in the past. Suffice it to say that I for one would find it useful.

[gfb107]

Changing how RM deals with required protocol code will be in the next release, as will showing the number of bytes used by the device upgrade code, the included keymoves, and the protocol code.

Changing RMIR to allow the association of keymoves and protocols to be turned on and off is a much bigger change. It'll be a while before I get to it.

I think I'll start an RM/RMIR To-do / Wish list thread to keep track of these things.

[Capn Trips]

Cool

[ElizabethD]

In the jet version - where will I find the RM error log?

[gfb107]

Probably in the installation directory.

[ElizabethD]

Thanks Greg, I found it. I think it was a refresh problem

[ElizabethD]

Having missed several versions, I thought I'd update myself here
In RM v1.90 and the Excelsior jet RM1.90, XP-SP3, java 1.6 I think, it says jre6 - some sort of numeric exceptions are happening.
I can't import few KM files I tried and have trouble describing it.
I locate the file, it comes in but nothing changes on display.
Then when I click the Functions tab and return to the Setup tab, the screen refreshes.
But still the only buttons assigned are 0-9 in the Dish upgrade, and none are assigned in the JVC upgrade most likely due to some numbers being wrong.

actualName='channel up'
java.lang.NumberFormatException: For input string: "03 - PAGE UP"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)

or in another file

Could not find function 1
actualName='2'
java.lang.NumberFormatException: For input string: "46 - Surround on/off"

The log that RM-jet version put out is slightly different but the result is the same.
Must be some minor glitch, bacause those KM imports worked fine before.

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