Page 8 of 14
Posted: Fri Apr 03, 2009 12:44 pm
by Nils_Ekberg
gfb107 wrote:So you are actually putting RM and IR in the same folder?
I'd do something like:
Code: Select all
C:\jp1\ir
C:\jp1\rm
C:\jp1\rm\Images
C:\jp1\rdf
C:\jp1\km
C:\jp1\Upgrades
C:\jp1\Config
Most of those are self explanatory.
Upgrades holds KM and RM upgrade files
Config holds .IR and .RMIR files
Mine is worse and I have done it this way forever
Code: Select all
c:/ir (IR & RM exe and jar, the dll's, sys, etc)
c:/ir/IR Devices (you guessed it .ir files)
c:/ir/RM Upgrades (Good guess again)
c:/ir/RDF (yup. RDF's)
c:/ir/Images (RM images)
I have a bunch of other folders but they are more a long the lines of dev folders for extenders etc.
Posted: Fri Apr 03, 2009 12:54 pm
by gfb107
Capn Trips wrote:
I DO put them in the same folder.
Why should there be two versions of the same dll?
There shouldn't be. The latest one will work with both. But until IR is packaged with the new one, you'll be stuck with this problem.
By putting them in the same folder, you can also share the same copy of DecodeIR.dll
Posted: Fri Apr 03, 2009 1:51 pm
by Capn Trips
gfb107 wrote:Capn Trips wrote:
I DO put them in the same folder.
Why should there be two versions of the same dll?
There shouldn't be. The latest one will work with both. But until IR is packaged with the new one, you'll be stuck with this problem.
By putting them in the same folder, you can also share the same copy of DecodeIR.dll
Precisely. I guess I'll just have to remember every time I download a new beta of IR, to NOT overwrite the jp12serial.dll file. (It's much easier, if one can just "extract all" and overwrite (presumably) older files).
Posted: Fri Apr 03, 2009 3:35 pm
by Capn Trips
bUMP!
Capn Trips wrote:A thought crossed my mind about the snazzy new setup code validation capability of this version of IR. I presume that it only cheCks the validity of setup codes entered on the General tab in IR, correct?
What about an alternate setup code that may be invoked by the Device Multiplexer or Device Toggler protocol? The alternate setup codes invoked by these Special Protocols do not appear on the General Tab. Will those get validity checked as well? (I suspect not yet)
Can IR be made to somehow identify an alternate code called in a Multiplexor keymove and perform the same check for any setup codes called therein?
Or is that a bridge too far?
Posted: Sat Apr 04, 2009 12:12 am
by Barf
mathdon wrote:... The SetupValidation entry in the [General] section takes one of the three values Off, Warn and Enforce. If set Off, ....
Strictly speaking, this is a configuration option for IR, not a property of the remote, and RDF files describes the latter. It would therefore be logical to move it to IR's configuration options.
Not a big issue though...
Posted: Sat Apr 04, 2009 6:05 am
by Capn Trips
Barf wrote:mathdon wrote:... The SetupValidation entry in the [General] section takes one of the three values Off, Warn and Enforce. If set Off, ....
Strictly speaking, this is a configuration option for IR, not a property of the remote, and RDF files describes the latter. It would therefore be logical to move it to IR's configuration options.
Not a big issue though...
Yeah, but....
In some remotes, entry of an invalid setup code will simply result in that particular device not working, in OTHERS, entry of an invalid setup code will lock up the entire remote, so in a way it IS a property of the remote.
Posted: Sat Apr 04, 2009 11:52 am
by unclemiltie
mr_d_p_gumby wrote:I agree that a single entry is preferable and more logical. I'm simply stating what we've had to do in the past in order to keep things from degenerating into chaos. Back when the RDFSpec was rolled from 2 to 3, the only program using RDF files was IR.exe (at that time maintained by it's original author). Since then, RM (& RMIR) and various other utility programs have been created that use the RDF files, and that makes the present situation more complex. The volunteer nature of the programming efforts here makes it difficult to coordinate a major change like this, since eveybody's time availability is different.
Oh, crap. I didn't think about this but mike brings up a good point. Extinstall reads the RDF as well, although I don't think it'll really care a whole lot about what you've done to the RDF, but I'm going to have to give it a whirl when I go and finally get back to speed on what you've done to the RDF.
Posted: Sat Apr 04, 2009 12:06 pm
by mathdon
Barf wrote:There are some bugs in the RDFs for urc-7780 and urc-7781: Entry for "9th Dev uses VPT" should read: "9th Dev uses VPT=$02A.0.1.0.0 (No;Yes)". Keycodes for Skip+ and Skip- are mixed up (I prefer "Next" and "Previous" as in some other RDFs, but that is not essential). The 7781 also has "HOM" entries 2200-2215 (as opposed to the 7780).
Many thanks for these corrections, Barf. The VPT one is long-standing and has gone un-noticed. The Skip- / Skip + mixup is mine, I'm afraid. I didn't like the names Start and End used in the original RDF for the URC-7780 and I slipped up in re-naming them. I agree that Previous and Next seem the best names. You are also almost right about HOM codes, but not quite. The values 2200-2215 are not additional to my list, the correct list is 0167 and 2200-2215. My translation from hex values to decimal didn't allow for codes > 2047, so my values 0152-0166 were out by 2048. I came up with 0167 twice and deleted the second entry, which should have been 0167+2048=2215. That duplication should have given the game away, but I'm afraid it didn't.
You really were eagle-eyed on this! I'll make the necessary corrections.
___________________
Graham
Posted: Sat Apr 04, 2009 12:20 pm
by mathdon
Capn Trips wrote:bUMP!
Capn Trips wrote:A thought crossed my mind about the snazzy new setup code validation capability of this version of IR. I presume that it only cheCks the validity of setup codes entered on the General tab in IR, correct?
What about an alternate setup code that may be invoked by the Device Multiplexer or Device Toggler protocol? The alternate setup codes invoked by these Special Protocols do not appear on the General Tab. Will those get validity checked as well? (I suspect not yet)
Can IR be made to somehow identify an alternate code called in a Multiplexor keymove and perform the same check for any setup codes called therein?
Or is that a bridge too far?
Sorry, Capn, I was busy preparing Beta 9. Your presumption is correct, only entries on the Device Buttons panel are checked. The driving force was remotes that crash when an invalid setup code is loaded, and this will occur immediately with invalid entries there. I take your point about Device Multiplexer having the ability to put in an unchecked invalid code, but unless others also feel strongly, I would prefer this to be a wish list item for a later release. I am hoping (third time lucky!) that Beta 9 will be the last Beta before general release.
_________________
Graham
Gee, you stay away for a while and things really change!
Posted: Sat Apr 04, 2009 12:46 pm
by unclemiltie
Graham
I love the code setup stuff. The Atlas remotes (can't remember on the 15-13x and 15-100) really don't like a setup code that is not valid and will go into an "infinite loop" that can only be exited with a battery removal. This will be a great feature for those remotes.
Not only that, because of the infinite loop problem, I built into the extenders the default setup codes for all of the devices. This prevents this from happening, but then overrides the setup codes when Extinstall runs so you have to change them back. I can now take the defaults out of the extender builds and IR will take care of this for me.
I take it I should "enforce" the setup code check so that the user can't upload something that is either not an upgrade or in the remote, correct?
mdavej and jgreenough, it appears that you have been working on the RDF's for these remotes. If you have, can you please email them to me at the address you already have? I'm in the midst of doing revs on all of the extenders to enable long-press-setup to deactivate the extender like I did on the 15-100. These will be incremental versions so I'll include these changes in the RDF's to support all of the new features of IR 8.
-bill
Posted: Sat Apr 04, 2009 1:23 pm
by The Robman
mathdon wrote:I take your point about Device Multiplexer having the ability to put in an unchecked invalid code, but unless others also feel strongly, I would prefer this to be a wish list item for a later release.
I definitely think this needs to be taken care of, but I totally agree that it can go on the wish list because it's not as urgent as the original setup code issue.
Keep in mind that people with a JP1 cable have the ability to re-load in order to fix the problem, so it's only people using WAV upgrades that would be SOL. I think that WAV file users are less likely to be loading things like the Device Multiplexor.
Posted: Sat Apr 04, 2009 1:24 pm
by Capn Trips
mathdon wrote:Capn Trips wrote:bUMP!
Capn Trips wrote:A thought crossed my mind about the snazzy new setup code validation capability of this version of IR. I presume that it only cheCks the validity of setup codes entered on the General tab in IR, correct?
What about an alternate setup code that may be invoked by the Device Multiplexer or Device Toggler protocol? The alternate setup codes invoked by these Special Protocols do not appear on the General Tab. Will those get validity checked as well? (I suspect not yet)
Can IR be made to somehow identify an alternate code called in a Multiplexor keymove and perform the same check for any setup codes called therein?
Or is that a bridge too far?
Sorry, Capn, I was busy preparing Beta 9. Your presumption is correct, only entries on the Device Buttons panel are checked. The driving force was remotes that crash when an invalid setup code is loaded, and this will occur immediately with invalid entries there. I take your point about Device Multiplexer having the ability to put in an unchecked invalid code, but unless others also feel strongly, I would prefer this to be a wish list item for a later release. I am hoping (third time lucky!) that Beta 9 will be the last Beta before general release.
_________________
Graham
Absolutely agree that this can be pushed to a "wish list". Just wanted to point it out. I've actually never tested it to see if calling an invalid setup code via multiplexor has any ill effect on my Atlas OCAP. (and I'm not inclined to do so. Barely enough time to program the remote CORRECTLY!)
Posted: Sat Apr 04, 2009 2:32 pm
by mathdon
unclemiltie wrote:I take it I should "enforce" the setup code check so that the user can't upload something that is either not an upgrade or in the remote, correct?
Correct. The intention was that "enforce" is only used for remotes that crash or otherwise misbehave when they encounter an invalid code, but you are talking about such remotes.
Barf wrote:mathdon wrote:... The SetupValidation entry in the [General] section takes one of the three values Off, Warn and Enforce. If set Off, ....
Strictly speaking, this is a configuration option for IR, not a property of the remote, and RDF files describes the latter. It would therefore be logical to move it to IR's configuration options.
Not a big issue though...
In principle I agree with you, but I hope the above explains why it was put in the RDF. I really don't want users of an affected remote to ignore the warning because they don't realise it is going to crash their remote.
__________________
Graham
Posted: Sat Apr 04, 2009 4:39 pm
by The Robman
I moved the "wish list" items to the wish list thread...
https://www.hifi-remote.com/forums/viewtopic.php?t=10799
Posted: Sun Apr 05, 2009 2:48 am
by Barf
Happy that my observations were useful.
You are also almost right about HOM codes, but not quite. The values 2200-2215 are not additional to my list, the correct list is 0167 and 2200-2215. My translation from hex values to decimal didn't allow for codes > 2047, so my values 0152-0166 were out by 2048. I came up with 0167 twice and deleted the second entry, which should have been 0167+2048=2215. That duplication should have given the game away, but I'm afraid it didn't.
...
I forgot that the setupcodes are taken mod 2048, so that the original list should be enough. (BTW, have you checked that the 7780 really supports them? They are not in the manual.) Bit: the problem is however that these codes are given as 2200 etc in the printed manual, IR accepts this, you can save and reload, and it is still 2200, not 152 (= 2200 mod 2048), the download works, but IR says (without 2200 in the RDF list) that it is invalid. This is a bug, and should be addressed. Two possibilites: reject/force change 2200 to 152, or check entered setupcode mod 2048.
To SetupValidation: The property of the remote is whether it goes nuts on invalid setup codes or not. Here is another suggestion:
Replace SetupValidation in RDF by (e.g.) HangsOnInvalidSetupcodes taking a value true/false. Introduce an IR-configuration option to suppress warnings for invalid setupcodes (or leave it out; the warnings are not intrusive). Then another IR-configuration option determines whether downloads should be refused if invalid setup codes are encountered, and the remote has HangsOnInvalidSetupcodes==true.
But of course it is more work.