Remote Master v1.88 is now available!

[gfb107]

I've built and released RemoteMaster v1.88

Available downloads are:

• RemoteMaster.v1.88.zip - (~0.9GB) Multi-platform Java program, works on Windows, Linux, etc..
  • Requires a Java 1.5 or newer runtime environment.
  • Please read and follow the installation instructions
• RemoteMaster_v1.88.exe - ( ~1.5GB) 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.88

• Better importing of KM upgrades that use Manual Settings
• RMIR: Fix importing of IR files that use undefined (not in RDF) keys in keymoves or macros.

Links:
The RemoteMaster project home page, now accepting donations.
RemoteMaster.v1.88.zip
RemoteMaster_v1.88.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.

[FernandoAdellan]

this version is instaled whit the name of version 1.87, but is the 1.88...

[gfb107]

Is this the Java version or the Windows version?

[mathdon]

Greg, I wonder if it would be possible for you to make one further minor change to RM. The discussions about IR.exe v8.00 have led to the view that there should be a way of specifying a default device setup code in the [DeviceButtons] section of the RDF. I have implemented this with the syntax

ButtonName=HiAddr LoAddr[ TypeAddr][, DevDefault]

i.e. the default setup code is separated from the existing parameters by a comma. RM at present accepts this syntax (it collapsed with a string of errors when I tried an alternative of putting the new parameter in brackets) but in the common case of TypeAddr being absent, I suspect it is interpreting DevDefault, which is then the third parameter, as a TypeAddr value. I don't think this has any effect in RM mode but it will do, of course, in RMIR mode.

Until such time as you want to make use of the DevDefault parameter, would it be possible for you to make a change so that anything after a comma in a [DeviceButtons] entry is ignored?

Graham

[gfb107]

I'll make the change, but I hate to do a full release cycle just for this.
I'm hoping to get some time to work on RMIR in the next couple of weeks, so I'll just include this in the next release.

[mathdon]

Greg, that's fine. There is no great hurry as the new ButtonName syntax has been chosen deliberately so that it works with RemoteMaster in RM mode as it is at present. This enables beta-testers of my IR 8.00 to create RDFs with default setup codes without breaking RM.

There won't be any such RDFs in the public domain for some time. All I want to avoid is such RDFs becoming public, apparently being accepted by the then current RemoteMaster but in fact being misinterpreted by RMIR, so creating faulty .ir files.

As far as I can tell, none of the other enhancements of RDF syntax cause problems for either RM or RMIR. They are either new entries in the [General] section, optional new parameters that follow mandatory parameters in existing entries, or changes in the [SpecialProtocols] section. I believe that all of these are ignored by RM and RMIR. The problem with the [DeviceButtons] entries is that the new optional parameter follows an already optional parameter and so can be mistaken for it whent the existing option is absent.

If you need to know more about the syntax changes, they are all described in the addendum to the RDF spec that is included in the IR 8.00 Beta zip file that you can find here. If anything does cause you a problem, please send me a PM (or post a message in the IR 8.00 beta thread).

Graham

[gfb107]

RMIR definitely uses the SpecialProtocols section, and it isn't necessarily true that the RM/RMIR RDF parser will ignore extra optional parameters for existing entries, especially for entries that currently only have one parameter.

[mathdon]

Sorry, Greg, for my misunderstandings. Apart from the DeviceButtons entries we've already discussed, the only case where there are new parameters added to an existing entry is for Labels in the [General] section, which adds two optional parameters to two existing mandatory ones. I hope that is OK with your present parser.

The [SpecialProtocols] section has substantially enhanced syntax, but you can get an "old" SpecialProtocols entry from the most general "new" one by treating the entry after the "=" as follows:

a) if there is a colon ":" in the entry, ignore it and everything before it
b) if the first character (after the colon, if there was one) is a minus "-", ignore it
c) take the first four characters of what is left as the Protocol ID - if this is not a valid hex value then ignore the whole entry
d) ignore anything following these four characters

It is possible that there will be two (or possibly more) entries for the Pause function that are distinguished from one another by info that you will be ignoring. After processing as just described, these will be identical. (They will have different PauseParams entries in the General section, but you will be ignoring them anyway). Ignore the duplicates if they will cause a problem for RMIR. In principle there can be multiple entries for other Special Protocols but as yet no-one has written an extender that will require this.

I'm sorry for the trouble that this is causing you, but I hope the above will enable you to extract valid data from an enhanced RDF without too much trouble.

I'm afraid I've done only a few trials with RMIR since I learned of its existence, so I was really going on what changes to an RDF caused RM to fall over or misbehave. Apart from the two remotes I have (URC-7781 and URC-8550), the only other .ir files I have are Rob's "FromRob" that comes in any IR.exe distribution, and two URC-6131 1K Extender 1 files I got from Bill. I can't get either the URC-7781 or Bill's files to load, even with RDFs that precede my enhancements. The URC-8550 file loads OK even with a new RDF that has default device codes in the DeviceButtons section (but for this remote they are a 4th parameter and so presumably ignored). The FromRob file also loads OK but I haven't played with its RDF. The ones that don't load don't give any error message, it is just that nothing appears in the panels.

Graham

[The Robman]

If you want more IR files to play with, look through the "Protocol Decodes" forum as most posts there start with the user posting learns of a new device.

[mathdon]

It isn't necessarily true that the RM/RMIR RDF parser will ignore extra optional parameters for existing entries, especially for entries that currently only have one parameter.

At that time I hadn't added an extra optional parameter to an entry that currently has only one. I'm sorry to have to tell you that I have now done so. It's pretty simple, but it will need your attention.

There is a TimeAddr parameter in the [General] section, used to specify an address for Day and Time data for remotes with an LCD day and time display that can set the day and time from the computer clock on an upload from IR.exe. I believe this has been dormant since it was introduced in 2002 for remotes using the Producer 8 chip. I now have it working again and Bill and I have tested it with our remotes. But current remotes need the data in a different format from the Producer 8, so the syntax is now

TimeAddr=Addr[, Format]

where format is one of Hex (default, Producer 8 format), BCD12 or BCD24 (US and European versions of the same thing, with either a 12 or 24 hour clock).

Bill tells me he gets an error message from RM when the second parameter is present. Could you please make RM ignore the second parameter (unless you want to make the minor change to handle it - if so, please let me know as I'll give you the details before I create the more general document we have discussed.)

Graham

[mathdon]

Compatibility problem solved!

Greg, I think I've solved the compatibility problem without you needing to do anything. See my latest post here.
_____________

Graham