New RDF and Maps/Image Release 1.30

[The Robman]

Any chance that you could make it configurable? I think the simplest way to do it would be to have a parameter that specifies the physical address where the date should be written.

I think I'd rather it just get written to one section rather than all of them.

How do you set up the display only stuff that you mentioned earlier?

[mathdon]

Any chance that you could make it configurable?

Yes, but I (and I suspect Mike too ) had hoped that we had finished with additions to the RDF Spec for quite some time, so it would not be my preferred choice.

I think the simplest way to do it would be to have a parameter that specifies the physical address where the date should be written.

If it is to be configurable, that would probably be the best way. I think the default, if this RDF item is missing, should be the present behavior.

How do you set up the display only stuff that you mentioned earlier?

Very simply. You add an entry of the form

Code: Select all

StartReadOnlySettings=12

to the [General] section of the RDF. That example would make the 12th and all following entries in the [Settings] section be read-only.

[mathdon]

One minor thing that I noticed with this RDF is that the AUX2 button defaults to LASER/0029, which is not a valid code. I suspect that the correct code is LASER/0059, which is present in the remote.

With the RDF I have, the @AUX2 button defaults to TAPE/0029, which is valid and correct. If it now defaults to LASER/0029 then that is a bug that has arisen in the latest juggling with the RDF, over the issues of "@ symbols" and duplicate device type aliases.

Rob, I don't know what is going on with this RDF, as I've just checked SourceForge for the latest version and there appears to be no change - the "duplicate" device types and "@" symbols are still there. I thought Chris was going to be changing it. If it hasn't changed, then unless you have modified your own copy (and this was one for which you posted a suggested change), you ought to get TAPE/029, just as I do.

EDIT: I've now looked at the latest RDF's for the Extender versions of the URC-8550 and see that they HAVE been changed. They are wrong. They make the default device type of the AUX2 button be LASER instead of TAPE. Your suggested change juggled the order of the entries in the [DeviceTypes] section. I posted a correction, but still followed your changed order. The first 8 entries must be in the order corresponding to the device buttons, the order of the remaining ones does not matter. You left the first 7 unchanged but put LASER in the 8th position. The TAPE device type needs moving up to be in the 8th position, above LASER. I take it that you did put your change, or my corrected version, into your own copy though it did not get into SourceForge for the unextended URC-8550.

[xnappo]

Hi Graham,

Sorry I screwed it up - I am unclear on exactly what needs to be done now even. Do you mind fixing them and checking them in?

Thanks,
xnappo

[mathdon]

Hi Graham,

Sorry I screwed it up - I am unclear on exactly what needs to be done now even. Do you mind fixing them and checking them in?

Thanks,
xnappo

Sure. We all screwed up. On the modification to the [DeviceTypes] section it was Rob and I that screwed up, Rob making the error and me not noticing it. On not dealing also with the unextended remote, that one does fall to you. I'll sort them all out.

[xnappo]

Hi Graham,

Sorry I screwed it up - I am unclear on exactly what needs to be done now even. Do you mind fixing them and checking them in?

Thanks,
xnappo

Sure. We all screwed up. On the modification to the [DeviceTypes] section it was Rob and I that screwed up, Rob making the error and me not noticing it. On not dealing also with the unextended remote, that one does fall to you. I'll sort them all out.

Thanks Graham!
xnappo

[Capn Trips]

I sort of just noticed that the RDF for the Comcast URC 1067B (JP1.3) Extender (3A393A39) is not in the current RDF release zip, nor does it appear in any of the "development" areas that I have been able to find. The RDF is included in the Apr 2009 extender zip file (v.1.00) and there is a newer RDF only in the diagnosis area with no explanation.

I have used this extender (with the newer RDF) on my father's setup in NJ and it seems to work fine. What needs to be done to "matriculate" this RDF to "official release" status?

[xnappo]

I have used this extender (with the newer RDF) on my father's setup in NJ and it seems to work fine. What needs to be done to "matriculate" this RDF to "official release" status?

Just need to check with the extender developer to see if they feel it is mature enough for release outside of the extender .zip. We don't want a case where the extender keeps getting updated and user's are unsure whether to use the RDF in the zip or from the library - so the plan is to wait until the extender is 'stable'.

xnappo

[3FG]

I run the 1067BX3 extender, using the RDF in the extender distribution. Works fine for me.

[Capn Trips]

That extender has had no development nor work done for months. I would argue that it's as "mature" as it's likely to get for now.

[xnappo]

That extender has had no development nor work done for months. I would argue that it's as "mature" as it's likely to get for now.

Okay - what I would like to have happen in a case like this is for someone else to move it into the development area here and let me know about it...

I can try to find it myself, but would be more comfortable if someone who is actually using it does it to ensure it is the right one.

Thanks,
xnappo

[3FG]

I've downloaded both rdf files (renaming one of them) and then used a utility to compare the files. The files are identical.

Capn Trips, please check to see if the RDF file you used is the same or different than the extender distribution. If the files are in fact the same, figuring out which one is better is a moot point.

[The Robman]

I just went to create an OBJ for ReplayTV and I discovered that the ReplayTV rdf is not in the distribution. I found it in the dev folder here:
http://www.hifi-remote.com/forums/dload ... le_id=7025

It's a finished RDF, so it should be included in the main zip file.

[Capn Trips]

EDITED: I agree that the two Comcast 3A393A39 rdf's are identical but are NOT ready for distribution. I moved it to the RDF development area.

Although the RDF is good, there is some incompatibility between the RDF and the Map file in the general Maps and Images distro. The CBL, FFWD, Rewind and Record buttons do not get highlighted on the Layout Tab. Instead they have "Phantom" buttons images created below the remote.

See this thread (that I finally located) where this was previously mentioned. Once Bill fixes the RDF in the extender distro zip, it ought to be good to go.

It turns out that MapThis won't run on my Win7 machine so I cannot try to fix the imagemap. I'll look at the RDFs to see if there is a naming inconsistency, since the UNEXTENDED image displays mapped keys correctly in RM.

[mathdon]

Some time ago, in this post:

Back to the question of the [DeviceTypes] list for the URC-8550, I have reviewed the data in it and I think the following replacement list should work:

Code: Select all

[DeviceTypes]
SAT        = 0
TV         = 0
VCR        = 2
CD         = 3
AMP        = 4, $0604
TUNER      = 4, $0605
MISC_AUDIO = 4
LASER      = 5
VID_ACC    = 0, $0008
DVD        = 3, $0709
HOME_CT    = 6, $060A
PHONO      = 3, $030B
CABLE      = 1, $000C
TAPE       = 6, $070D
DAT        = 6, $070E

There have been various posts since about errors in this revised list, and I said I would sort it out. I've just got round to doing so but have hit on a big snag. Any revision that removes the duplicate AMP and TUNER entries that were the cause of Rob's revision removes from the RDF some values for that 2-byte second field (remember, there is a default value for the entries that don't have this second field explicitly) that are valid in, and can be set by, the remote. If the remote, or an existing .ir file, contains one of these missing entries, it causes an error in IR.exe.

It therefore seems to me that we are stuck with the duplicate device types in order for IR.exe to be able to read any possible download from the remote. So I suggest that we go back to the original list for the [DeviceTypes] section for the various URC-8550 RDFs.