JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RDF Development and Maintenance Process
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs
View previous topic :: View next topic  
Author Message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

                    
PostPosted: Wed Apr 28, 2010 2:37 pm    Post subject: Reply with quote

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.
_________________
Mike England
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Wed Apr 28, 2010 2:48 pm    Post subject: Reply with quote

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.
_________________
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
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Wed Apr 28, 2010 2:50 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Wed Apr 28, 2010 3:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Wed Apr 28, 2010 3:55 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 1:51 am    Post subject: Reply with quote

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

Smile 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") Wink

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:
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:
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
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 9:17 am    Post subject: Reply with quote

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.

Quote:
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.
_________________
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
View user's profile Send private message Visit poster's website
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 9:32 am    Post subject: Reply with quote

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 )
Back to top
View user's profile Send private message Visit poster's website
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 9:44 am    Post subject: Reply with quote

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


Last edited by jimdunn on Thu Apr 29, 2010 9:55 am; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 9:52 am    Post subject: Reply with quote

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.
_________________
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
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 10:01 am    Post subject: Reply with quote

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


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 Laughing). I often miss-enter numbers, so I often inadvertantly get my remotes to reset.
_________________
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
View user's profile Send private message Visit poster's website
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 10:04 am    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message Visit poster's website
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 10:19 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 10:21 am    Post subject: Reply with quote

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


Yeah - maybe Smile

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.
Back to top
View user's profile Send private message Visit poster's website
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 10:31 am    Post subject: Reply with quote

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 Smile - 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.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 3 of 7

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control