 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
 Posted: Sat Jul 10, 2010 10:01 am Post subject: |
 |
|
| gfb107 wrote: |
And changing the checking tool rather than the RDFs or RM avoids the version dependency problems between RM and the RDFs altogether. |
Okay, we will go that route then.
xnappo |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sat Jul 10, 2010 10:33 am Post subject: |
|
|
| mathdon wrote: | | 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). |
If this is true, don't you think it's somewhat dangerous to have HT be available as a general device mode? As things stand, there's nothing stopping people from creating upgrades using HT as the device mode and then adding them to IR.
My vote would be to eliminate HT as a valid device mode, which will eliminate the chance of someone using it as a device mode in RM, and then add some logic to IR to handle the assignment of HT mode to one of the device buckets. The new logic should be configurable in the RDF so that the next remote that acts like the URC-7780, but with slightly different settings, can be made to work.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Sat Jul 10, 2010 10:47 am Post subject: |
|
|
While it is true someone could upload an upgrade using the HT device, this is just the same as someone uploading an upgrade using OEM Mode right? And most remotes aren't going to have an OEM Mode so that won't really work right.
Basically, along with the upgrade coding guideline of including all original remote buttons, we should also request that HT and OEM Mode are not used.
xnappo |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Sat Jul 10, 2010 11:34 am Post subject: |
|
|
I don't think KM knows about the HT device type, so there's no way it can create an HT device upgrade. RM allows only the device type aliases that are defined in the RDF for a remote. So if we don't define a device type alias for the HT device type in the RDF, there's no way to create an upgrade for the HT device type.
I see that IR allows changing the device type of an installed upgrade to HT, which is still a problem.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Jul 23, 2010 7:21 am Post subject: |
|
|
Now that we have the [SetupCodes] section in all RDFs, so that Code Validation works, I would like to return to an issue that was discussed at some length earlier last year. There was a general consensus that we should work towards making an RDF on its own, loaded through File/New in IR.exe, create a valid image equivalent to a Factory Reset of the remote.
Here are some excerpts from the discussion. More details can be found by clicking on the links and browsing the surrounding messages.
From this post:
| The Robman wrote: | | So what we need is the ability to specify the default setup codes for each device button in the RDF, right? |
then:
| The Robman wrote: | As I think we're headed towards making the RDFs create a "new" image that almost exactly replicates a virgin image, I think it might be a good idea to sneak in something so that we can tell when an IR file was created this way, just to help us diagnose possible problems.
I'm thinking that whenever someone uses the New > Select method of creating an IR file, IR could put a little signature of sorts near the end of the IR file, like maybe a couple of bytes with the value $1234. |
and:
| mathdon wrote: | Bill wrote:
| Quote: | The setup codes are not the only thing, there is some other stuff. For example, the Comcast DVR has some things in there that I don't quite understand but if one of them is not $0F the remote uses the value in there for the device for all macros. Then if the device is greater than $03 the remote goes to never-never land.
|
It is this other stuff that made me introduce "read-only settings". You don't even need to know what the byte does, just what its value in a 981 reset should be. Give such settings innocuous names such as Aux1, Aux2,... - it really doesn't matter. If the user can't change the value, he/she doesn't need to know what it is for. But I think it is helpful for diagnosis, experiment, etc to have such values displayed. (I suppose I could even create "invisible" settings that are used in initialization but are not displayed, if that was felt to be better.) |
and:
| The Robman wrote: | we need to make the RDFs able to create good virgin images. The marker that I suggested would only be added to images that were created using the New > Select option as it would tell us how the IR file was initially created. There would be no need for IR to ever get rid of the marker, and if it gets overlaid with valid data (eg, learned signals or upgrades) so be it. In fact, now that I think of it, rather than using a hard code marker, maybe we could make it a date. We could fit a date into 3 bytes (eg, $02 07 09).
If someone has problems with an IR file, the marker would tell us that it was created using IR.exe and the date would tell us how recently. So, if it's an old file, the problem is probably something else, but if it's new, then maybe there's a byte of data that should have been set but IR.exe didn't set it.
I like the idea of display only data too. |
The ability to specify default setup codes in the [DeviceButtons] section and read-only settings through a parameter in the [General] section are in version 4 of the RDF Specification and have been implemented in IR.exe since version 8.00. It even puts in the date, in a year/month/day format, at the end of the Advanced Code section as the marker that Rob asked for.
I did one RDF of a fairly complicated remote as an example. This one creates a Factory Reset image when loaded through File/New:
ET80ET80 (URC-8550_5550 Topline).rdf
I can't put a link to it now that they are all on SourceForge, but it is in the recent zip file of RDFs.
With RDFs now under active development once again, it would be very good if this could be done for all RDFs.
_________________
Graham |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Fri Jul 23, 2010 8:38 am Post subject: |
|
|
All well and good for non OEM remotes, but with our OEM remotes, there are all sorts of setups that vary by provider.
I've been a JP1 user for 10 years, and before Graham added the RDF Edit buttons, I had never done a File->New because early on it was drummed into my head to let IR choose for me.
Perhaps the File->New should carry a warning. File->News will give you all sorts of problems.
Oh cr** I probably should address this in help. 
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Fri Jul 23, 2010 9:07 am Post subject: |
|
|
You should always start with dumping the remote whenever possible, but as long as the File>New option is there, there will be somebody who will use it. Plus, it's useful to have for situations where you don't have the remote in your hands (perhaps because you're setting one up for someone else).
I don't think it was ever the intention for this option to replicate the factory settings of an OEM remote, in other words, it won't pre-load any upgrades that might have been loaded at the factory. The intention is to replicate the memory image that you would get if you pre-loaded the EEPROM with all FFs and then did a 981 reset (ie, what we call a "virgin" dump).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Fri Jul 23, 2010 10:28 am Post subject: |
|
|
xnappo,
Using IE8 with no SourceForge account, your link brought up the text of the rdf file. I copied and pasted into Notepad, then copied and pasted the file name from Graham's post into the SaveAs dialog.
I haven't tested the resulting file, but it looks perfectly normal.
Last edited by 3FG on Fri Jul 23, 2010 10:28 am; edited 1 time in total |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Fri Jul 23, 2010 1:29 pm Post subject: |
|
|
| mathdon wrote: | | The ability to specify default setup codes in the [DeviceButtons] section and read-only settings through a parameter in the [General] section are in version 4 of the RDF Specification and have been implemented in IR.exe since version 8.00. It even puts in the date, in a year/month/day format, at the end of the Advanced Code section as the marker that Rob asked for. |
I like it. Is the position of the date configurable in the RDF? My preference would be to position it at the end of the upgrade section as this is less likely to get filled with user data than the advanced code section. Another possibility is the learning section.
| mathdon wrote: | I did one RDF of a fairly complicated remote as an example. This one creates a Factory Reset image when loaded through File/New:
ET80ET80 (URC-8550_5550 Topline).rdf |
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
gfb107
Expert
Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC
|
| Posted: Fri Jul 23, 2010 2:40 pm Post subject: |
|
|
| 3FG wrote: | xnappo,
Using IE8 with no SourceForge account, your link brought up the text of the rdf file. I copied and pasted into Notepad, then copied and pasted the file name from Graham's post into the SaveAs dialog.
I haven't tested the resulting file, but it looks perfectly normal. |
I think you could right-click on the text view (or the link itself) and select Save As... and then all you have to choose is the destination folder, the file name would be filled in for you.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Fri Jul 23, 2010 4:36 pm Post subject: |
|
|
| Yes, it does do that. |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Jul 23, 2010 4:45 pm Post subject: |
|
|
| The Robman wrote: | | 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.
_________________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Jul 23, 2010 4:48 pm Post subject: |
|
|
| The Robman wrote: | | Is the position of the date configurable in the RDF? |
No, it's not configurable but there is no reason why it could not be written at the end of more than one section. It does no harm and it serves its purpose if at least one of them survives.
_________________
Graham |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
