JP1 Remotes

Posted: **Fri Jul 09, 2010 2:33 pm**

Does this mean we're OK requiring device type aliases for every device type because the RDFs with the @* device types and HT device types were wrong?

Posted: **Fri Jul 09, 2010 3:29 pm**

gfb107 wrote:Does this mean we're OK requiring device type aliases for every device type because the RDFs with the @* device types and HT device types were wrong?

That does appear to be the case, yes.

Posted: **Fri Jul 09, 2010 3:32 pm**

xnappo wrote:Thanks very much Rob! Especially for the detailed explanation and research on point 2.

The RDFs with HT as a device type are:
10621062 (URC-7780 One For All Stealth 12).rdf
11311131 (URC-7781 One For All Digital 12).rdf

Thanks,
xnappo

I've looked at those and I see no reason to keep the HT device types.

Posted: **Fri Jul 09, 2010 3:43 pm**

Thanks very much Rob.

I will work on getting a new release going with these inputs ASAP.

xnappo

Posted: **Fri Jul 09, 2010 4:54 pm**

The Robman wrote:I've looked at those and I see no reason to keep the HT device types.

Rob, I don't think you have ever seen a URC-7781 or know much about how it works. The HT type is ESSENTIAL. It is treated internally as a device type, can be set up in a device slot, is assigned (invisibly) a setup code that is treated specially within the programming of the remote and has corresponding special treatment in IR.exe (and now, also in RMIR). If you remove it from the RDF you will undo a lot of the effort I have put in to getting IR.exe to handle ALL the functionality of the URC-7780 and URC-7781.

I am surprised, to say the least, that you wrote that sentence without thinking of consulting me. It was my desire to get IR to work properly with my URC-7781 that brought me into the JP1 group in the first place.

If my opinion is worth anything, I think it should not be assigned a device alias. If RMIR wants to check the existence of device aliases for everything else, the HT type is identified by the SoftHT entry in the [General] section of the RDF, which could be used to exclude it from the need for a device alias.

Posted: **Fri Jul 09, 2010 5:02 pm**

mathdon wrote: If RMIR wants to check the existence of device aliases for everything else, the HT type is identified by the SoftHT entry in the [General] section of the RDF, which could be used to exclude it from the need for a device alias.

I hate to keep asking - but can't I just assign it as 'OEM Mode'? It doesn't seem like that will hurt anything, and follows what I plan to do for other things that don't really fit into a normal category.

No one is going to use 'HT' as the device type in an upgrade they would submit to the files section right? So the alias is really just a placeholder...

xnappo

P.S.That is a really nice looking remote. I wish they sold that here.

Posted: **Fri Jul 09, 2010 6:02 pm**

mathdon wrote:I am surprised, to say the least, that you wrote that sentence without thinking of consulting me. It was my desire to get IR to work properly with my URC-7781 that brought me into the JP1 group in the first place.

You'll be surprised to learn that I don't have everybody's remotes memorized, so I don't know who to consult for each individual remote model.

If you have input regarding the HT device mode, you should post it and not leave it to others to speculate.

Posted: **Fri Jul 09, 2010 6:35 pm**

The Robman wrote:
If you have input regarding the HT device mode, you should post it and not leave it to others to speculate.

Well to be fair, Graham did - on page 4 of this thread, but it did not resolve how to fix the check for an alias, which I would really like to do so that I can have a clean verification of compliance to having an alias - which is *usually* a good idea in Vicky's tool...

So.. Again HT=OEM Mode alias should not cause any problems right?

xnappo

Posted: **Fri Jul 09, 2010 8:44 pm**

xnappo wrote:Well to be fair, Graham did - on page 4 of this thread, but it did not resolve how to fix the check for an alias, which I would really like to do so that I can have a clean verification of compliance to having an alias - which is *usually* a good idea in Vicky's tool...

So.. Again HT=OEM Mode alias should not cause any problems right?

xnappo

I came back to this thread when you asked me to in another thread, so I did my best to answer your current questions. If Graham had an opinion about your questions, it would have better to post an answer then you wouldn't have needed to call me into the fray and I wouldn't have had to speculate an answer that he didn't like.

Quite simple really, if you don't speak up, others will.

As for your remaining question, maybe the best approach is for me to answer it as, if I give the wrong answer, it will undoubtedly prod Graham into answering it correctly. So yes, please associate HT with OEM mode.

Posted: **Fri Jul 09, 2010 9:23 pm**

I think Graham answered the question. He said the HT device should not be assigned any device type aliases, and RM should be changed to allow for that.

Of course that doesn't give you a short term solution to the problem.
In the short term, I think it is reasonable to use OEM Mode for HT.

In the near/mid term, RM will be changed to specifically not require a device type aliases for the HT device type, but also ignore any device type aliases that are defined for the HT device type.

In the long term, you can update the RDFs to remove any device type aliases assigned to the HT device type.

Posted: **Sat Jul 10, 2010 2:11 am**

The Robman wrote:If you have input regarding the HT device mode, you should post it and not leave it to others to speculate.

You mean like this post in this thread six days ago when xnappo first raised the issue of an alias for the HT type?

Posted: **Sat Jul 10, 2010 2:32 am**

gfb107 wrote:I think Graham answered the question. He said the HT device should not be assigned any device type aliases, and RM should be changed to allow for that.

Of course that doesn't give you a short term solution to the problem.
In the short term, I think it is reasonable to use OEM Mode for HT.

I will go along with this, but I don't actually understand the need for the short-term solution. Greg will correct me if I am wrong, but I haven't found that not having an alias for HT causes any problems with IR or RMIR. Its absence causes an entry in rmaster.err, but nothing of operational significance. The ONLY problem seems to be that Vicky's checker picks up this absence and gives a warning. My short term solution would be: ignore this warning.

Could an alias of OEM Mode cause a problem? Yes. If converting from a device with the OEM Mode alias on some other remote to a URC-7781, it would use the HT type, which is meaningless. It would also, almost certainly, use an invalid setup code for this type. There are exactly two valid setup types for the device index 15 (which is HT). One is $FFF, signifying that the device slot is empty. The other is $3F3, signifying that the slot has been assigned to HT (Home Theater).

So my preferred short term solution is the same as the long term one, leave out the alias.

Incidentally, does it really make sense to map from OEM Mode on one remote to that on another, if this alias is used for something specific to a particular remote?

Posted: **Sat Jul 10, 2010 2:51 am**

The Robman wrote: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

I don't think this will work as it stands. The RDF Spec says

If DevTypeNum is omitted, it will initially default to 0 and increase by $0101 for each subsequent entry.

So the implicit DevTypeNum entries for MISC_AUDIO and LASER would be $0706 and $0807. The correct values need to be put in explicitly, so the list should be:

Code: Select all

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

Posted: **Sat Jul 10, 2010 8:15 am**

Thanks Greg, Graham and Rob.

The ONLY reason I want to alias it to 'OEM Mode' is for completeness so that the RDF checking tool run cleanly(thinking that someday someone else may be running it). Yes we could modify RM and the checking tool to ignore HT, but I don't really think it is necessary. If 'OEM Mode' is used for any alias that doesn't translate between remotes, I think that is fine.

Ideally we would just add a type 'Other' to the RDF spec as just fixing HT leaves the door open for some other strange device type in a future remote... But I am fine with using 'OEM Mode' to basically mean 'Other' if y'all are.

xnappo

Posted: **Sat Jul 10, 2010 8:59 am**

If RM really does not need the HT device type to have any aliases (I haven't tried, but I believe Graham), the RDF checking tool should be changed to reflect that.

After all, RM is the only tool that uses device type aliases. It makes no sense to allow users to create unusable/meaningless upgrades for the HT device type, or to map upgrades that use the OEM mode alias to the HT device type. It's better to get a message that the upgrade can't be loaded because there is no matching device type.

And changing the checking tool rather than the RDFs or RM avoids the version dependency problems between RM and the RDFs altogether.

JP1 Remotes

New RDF and Maps/Image Release 1.30