JP1 Remotes

Posted: **Wed Apr 28, 2010 1:37 pm**

vickyg2003 wrote:I went with
SetupValidation=Warn
If you see a spelling problem speak up now.

I agree, except that if the RDF already has an Enforce setting (ex: Graham's 7780 RDFs), I'd leave it that way.

Posted: **Wed Apr 28, 2010 1:48 pm**

mr_d_p_gumby wrote:
vickyg2003 wrote:I went with
SetupValidation=Warn
If you see a spelling problem speak up now.
I agree, except that if the RDF already has an Enforce setting (ex: Graham's 7780 RDFs), I'd leave it that way.

I was told to add them to RDF's where they were not present. If they are there I proceed to the next RDF.

Posted: **Wed Apr 28, 2010 1:50 pm**

The original intention was that "Enforce" was only for those remotes, such as the URC-7780, that crash if invalid setup codes are entered. "Warn" was the standard value, intended for all others (including the URC-7781, that is very similar but which does not have that problem). I hope that this rationale will continue to be followed.
______________
Graham

Posted: **Wed Apr 28, 2010 2:53 pm**

Hmm... Do we know what other remotes could crash with invalid setup codes? I've had extended 15-13x's crash (or at least do very strange things) due to invalid codes, but not unextended.

I'm wondering if such a setting belongs in IR instead of in the RDF. It does put the decision to risk a crash in the user's hands, but at least the choice wouldn't be hard-coded, so to speak.

Posted: **Wed Apr 28, 2010 2:55 pm**

mdavej wrote: I'm wondering if such a setting belongs in IR instead of in the RDF. It does put the decision to risk a crash in the user's hands, but at least the choice wouldn't be hard-coded, so to speak.

That is why I like 'warn' instead. We allow IR/RM-IR to write a totally different remote signature with just a warning - so I think a warning is fine as long as it explains the risk.

xnappo

Posted: **Thu Apr 29, 2010 12:51 am**

xnappo wrote:so I think a warning is fine as long as it explains the risk.

It should be, shouldn't it ?

Problem is that Microsoft (and others) have "trained" users to "just click ok" on warnings by the sheer preponderance of (often badly worded) warnings/errors in confusing or inappropriate places.

Many of the support calls I get involve the following "diagnosis" (or similar) from the user:
"Then it came up with some kind of error thingie, and I clicked OK..."
...
"No - I didn't read it - I just clicked ok to see if it would work anyway"

And in the users' defence - this strategy will often get them the result they want - so I can't entirely blame them for trying this approach (especially if they are "not technical")

That's why I think it's important to retain "Enforce" where the danger exists of putting the remote into a "non-working" state.

xnappo wrote:We allow IR/RM-IR to write a totally different remote signature with just a warning

It's the only way you can load an extender into an unextended remote (or vice-versa) - so harder, I guess, to avoid without something like defining valid alternative signatures in the rdf
(which sounds like a nightmare to implement and keep up to date)... (but I do see your point)
___________________________________________________________

mdavej wrote:Hmm... Do we know what other remotes could crash with invalid setup codes? I've had extended 15-13x's crash (or at least do very strange things) due to invalid codes, but not unextended.

unclemiltie's Atlas/Atlas OCAP JP1.3 Extender (Version 2.10) Readme says:

Extender Readme wrote:These remotes are dependent on the setup codes for the devices being either present in the base ROM or in the upgrade table. The remote checks all of the device setup codes on reset and if the devices are not present the remote will erase the area of the EEPROM where the extender resides and will reset the signature to the unextended signature. The
extender is shipped with default device setup codes in place for all devices. If you change the setup codes and on reset you see the LED blink 5 times, you can be assured that the extender has been erased and the signature has revered to the old signature.

...

A built-in failsafe in the extender will detect that the signature has changed and will operate as an unextended remote until a new version of the extender has been uploaded with the extender signature in place. While operating as an unextended remote, the LED will blink twice for every keypress to indicate that the extender is not being used. While
the extender is not being used, none of your keymoves or macros will be valid.

and I can confirm that you need to use valid codes with this extender.

I edited my own copies of these rdf's to include the setup codes and

Code: Select all

SetupValidation=Enforce

because the extender just doesn't work with invalid setup codes, triggering the above described behaviour.

So this is another case where "Enforce" should be in the rdf.

It's important here because these extenders stay resident across a battery change - and you need to execute a special keymove to deactivate the extender, before reloading any unextended IR backups you may have.

Preventing the aberrant upload could save users a lot of confusion with this extender. (I speak from personal experience...)

This would apply to:

Code: Select all

3A003A00 (Atlas 5 Day URC-1055_11055 JP1.3 3000 extender v2.10).rdf
3A333A33 (Atlas 5 Day URC-1055_11055 JP1.3 3033  extender V2.10).rdf
3A333A33 (Atlas OCAP URC-1056 JP1.3 (Black)_(Silver)  extender V2.10).rdf

Posted: **Thu Apr 29, 2010 8:17 am**

I do believe that Unclemiltie will be updating his extender RDF's himself, as he doesn't want them in the distbribution file. As you have noted, the stay resident extenders are a bit tricky and Bill wants to be in charge of his own RDF's because making changes to the RDF requires special skills.

The remote checks all of the device setup codes on reset and if the devices are not present the remote will erase the area of the EEPROM where the extender resides and will reset the signature to the unextended signature.

99% of remotes just reset if the setup codes are invalid after the restart. How often did you have it that the remote didn't download what you uploaded. However there are a couple of remotes that don't do the reset, they just keep looping through, check that its invalid, and restart without doing the reset, do the check, fail, restart, do the check, fail, restart......

And as you pointed out, the reset will wipe out any extender that's in the E2 area and will change all the setupcodes to the setupcodes that came from the factory.

Posted: **Thu Apr 29, 2010 8:32 am**

vickyg2003 wrote:I do believe that Unclemiltie will be updating his extender RDF's himself, as he doesn't want them in the distbribution file.

ok - they were in the last zip I downloaded (1.28)

I used the ones from the extender zip anyway - but added the setup codes section and "Enforce" line to the rdfs for my own convenience.

Maybe the solution for rdf management is to only let the registered (or an approved) "author" of particular rdfs check them in/approve them - then unclemiltie (in this case) can keep control, but they can still be in the common zip ?

I guess xnappo might be able to clarify how/by whom a "checked in" rdf will get approved for inclusion in the "release" zip. (sorry if he already posted that and I missed it )

Posted: **Thu Apr 29, 2010 8:44 am**

vickyg2003 wrote: 99% of remotes just reset if the setup codes are invalid after the restart.

Truly ?

I've never had that problem except when I started using the Atlas extenders.

My memory tells me that when I added [SetupCodes] sections and the SetupValidation= line to my rdfs for extended/unextended 8910/7560/7562, IR started highlighting "red" invalid setup codes I'd had in working setups (on device buttons I never used) for ages without ever crashing a remote.

But my memory tells me lies sometimes, too...

Or is this just a JP1.x thing ?

In which case my only experience is with the Atlas 3033, and then it's 100% true.

Posted: **Thu Apr 29, 2010 8:52 am**

Well there are pros and cons of letting your extender rdf's be in the common file. I've submitted mine, because when I get the new rdf's I erase everything in my RDF directory to make sure that I'm not dealing with obsolete files, that might have been renamed..... So I get my files right there with one unzip.

As long as an extender writer hasn't gone AWOL, its best to let them choose whether to have their RDF's included in the common zip or not.

Posted: **Thu Apr 29, 2010 9:01 am**

jimdunn wrote:
vickyg2003 wrote: 99% of remotes just reset if the setup codes are invalid after the restart.
Truly ?

I've never had that problem except when I started using the Atlas extenders.

My memory tells me that when I added [SetupCodes] sections and the SetupValidation= line to my rdfs for extended/unextended 8910/7560/7562, IR started highlighting "red" invalid setup codes I'd had in working setups (on device buttons I never used) for ages without ever crashing a remote.

But my memory tells me lies sometimes, too...

Or is this just a JP1.x thing ?

In which case my only experience is with the Atlas 3033, and then it's 100% true.

The JP1.3 extenders crash, on reset. The other remotes don't crash on reset, they just go back to the way they came from the factory. Sometimes the reset happens on restart, sometimes it doesn't happen until you press a key that has an invalid setup, but yes this appears to happen with all my remotes. Perhaps I notice it more than you would have because of my dyslexia. (no printer history here

). I often miss-enter numbers, so I often inadvertantly get my remotes to reset.

Posted: **Thu Apr 29, 2010 9:04 am**

vickyg2003 wrote:Well there are pros and cons of letting your extender rdf's be in the common file.

I can certainly see that.

If your extender is under development or there is a new revision, the last thing you want is your carefully crafted rdf from your zip being "clobbered" when the user updates his local rdfs from the distribution zip - because the version in the zip is out of date.

Problem arises because the extender developer is releasing an rdf with the extender zip which may be newer than the "released zip" version - and the method of installing the zip is to overwrite.

So do extenders always need to be separate ?

Or just until it's "mature" and specified as such by the author - (for instance the "mature" 8910 extender is fine in the zip) ?

I don't know - but it seems to beg discussion...

Posted: **Thu Apr 29, 2010 9:19 am**

jimdunn wrote:
I don't know - but it seems to beg discussion...

Personally I think this should follow the process I outlined.

When an extender is in development, keep the RDF with the extender or in the development folder. When the RDF is mature, it should be moved into revision control.

If an update to a mature RDF is needed, the author should either check in the change themselves or contact one of the SourceForge developers to do it for them.

Otherwise we will run into issues with people winning the lottery etc. when we want to make some general improvement 8 years from now (like we are now with making sure protocols and updates are correct and making sure filenames are Linux friendly).

xnappo

Posted: **Thu Apr 29, 2010 9:21 am**

vickyg2003 wrote: Perhaps I notice it more than you would have because of my dyslexia. (no printer history here )

Yeah - maybe

You do about a million times more work in that area than I ever could - so I guess I just never triggered it in those old setups.

Posted: **Thu Apr 29, 2010 9:31 am**

xnappo wrote:
jimdunn wrote:
I don't know - but it seems to beg discussion...
Personally I think this should follow the process I outlined.

When an extender is in development, keep the RDF with the extender or in the development folder. When the RDF is mature, it should be moved into revision control.

If an update to a mature RDF is needed, the author should either check in the change themselves or contact one of the SourceForge developers to do it for them.

Otherwise we will run into issues with people winning the lottery etc. when we want to make some general improvement 8 years from now (like we are now with making sure protocols and updates are correct and making sure filenames are Linux friendly).

xnappo

Absolutely agree - but the only question then remaining is who can check in the "mature" file and declare it mature.

The process works because Bill can keep his extenders "under development" until he's happy to release them to the distribution, and that can be whenever he's comfortable.

Or when (NOT if

- cos he will, you know...) he wins the lottery, those who remain can declare it mature in his absence, and send him a postcard in the Caymans.

Old extenders like 8910 would just "default" to mature now.

So long as only "trusted" rdf developers can check in a final version this process seems to work perfectly - since everyone can obviously co-operate there.

I'm certainly not trying to criticise the process - if anything, just trying to understand it.

And any well considered process is bound to be better than the lack of one - so I think what you're doing here is admirable, and essential.

JP1 Remotes

RDF Development and Maintenance Process