IR.exe v8.00 Beta now posted

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Apr 03, 2009 12:44 pm

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.

gfb107 · Post by **gfb107** » Fri Apr 03, 2009 12:54 pm

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

Capn Trips · Post by **Capn Trips** » Fri Apr 03, 2009 1:51 pm

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).

Capn Trips · Post by **Capn Trips** » Fri Apr 03, 2009 3:35 pm

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?

Barf · Post by **Barf** » Sat Apr 04, 2009 12:12 am

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...

Capn Trips · Post by **Capn Trips** » Sat Apr 04, 2009 6:05 am

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.

unclemiltie · Post by **unclemiltie** » Sat Apr 04, 2009 11:52 am

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.

Post by **mathdon** » Sat Apr 04, 2009 12:06 pm

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

Post by **mathdon** » Sat Apr 04, 2009 12:20 pm

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

unclemiltie · Post by **unclemiltie** » Sat Apr 04, 2009 12:46 pm

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

Post by **The Robman** » Sat Apr 04, 2009 1:23 pm

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.

Capn Trips · Post by **Capn Trips** » Sat Apr 04, 2009 1:24 pm

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!)

Post by **mathdon** » Sat Apr 04, 2009 2:32 pm

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

Post by **The Robman** » Sat Apr 04, 2009 4:39 pm

I moved the "wish list" items to the wish list thread...
http://www.hifi-remote.com/forums/viewtopic.php?t=10799

Barf · Post by **Barf** » Sun Apr 05, 2009 2:48 am

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.

JP1 Remotes

IR.exe v8.00 Beta now posted

Gee, you stay away for a while and things really change!