RMIR: Prototype IR function in RM

[xnappo]

Not saying we should use it, but if you want to try here is a link to the SourceForge feature request tracker:
https://sourceforge.net/tracker/?group_ ... tid=399669

And bug tracker:
https://sourceforge.net/tracker/?group_ ... tid=399666

Click 'Add New' to enter a new one. This would be the 'nicest' way to keep track of this stuff, however it needs to be easy for people to use too - so give it a try.

You do need to log in, but you can use a wide variety of accounts you already have (google, yahoo, aol, etc)

xnappo

[gfb107]

Greg - should we start a seperate thread ONLY for feature requests/bug reports (discussion of the request/feature to be held elsewhere)?

xnappo

We could use the RMIR To-do List and Wish List thread.

[gfb107]

Not saying we should use it, but if you want to try here is a link to the SourceForge feature request tracker:
https://sourceforge.net/tracker/?group_ ... tid=399669

And bug tracker:
https://sourceforge.net/tracker/?group_ ... tid=399666

Click 'Add New' to enter a new one. This would be the 'nicest' way to keep track of this stuff, however it needs to be easy for people to use too - so give it a try.

You do need to log in, but you can use a wide variety of accounts you already have (google, yahoo, aol, etc)

xnappo

I agree it would be the nicest from our point of view.

Also, for anyone who tries it out, please be aware that we can add/rename/remove the values for many of the fields to be more applicable to RMIR. What you see there now is either the default or what was setup originally before I ever started working on RM/RMIR.

[The Robman]

I think the table cell is selected, not the cell contents.

I just did some experimenting in Excel to see what it does and when the cell itself is highlighted and you start typing it does overlay the contents, so even if in RM it's the cell and not the contents that are highlighted, the normal expectation is that any new typing should overlay the contents.

[Capn Trips]

Greg - should we start a seperate thread ONLY for feature requests/bug reports (discussion of the request/feature to be held elsewhere)?

xnappo

We could use the RMIR To-do List and Wish List thread.

I have used that thread in the past, but it seemed to die out - as did, apparently the requests included therein. If the requests are still in the queue for future implementation, OK, I guess I'll continue waiting.

[gfb107]

Greg - should we start a seperate thread ONLY for feature requests/bug reports (discussion of the request/feature to be held elsewhere)?

xnappo

We could use the RMIR To-do List and Wish List thread.

I have used that thread in the past, but it seemed to die out - as did, apparently the requests included therein. If the requests are still in the queue for future implementation, OK, I guess I'll continue waiting.

It's the closest thing we currently have to an official to-do/known issue list.

[Capn Trips]

Bug Report: Related to my earlier post today about an error when opening an OCAP file, I modified the RDF as suggested and RMIR now downloads from the extended remote correctly, but it simply ignores the matching IR file when I try to open it in RMIR.

Help?

For this case you should post rmaster.err for Greg.

xnappo

http://www.hifi-remote.com/forums/dload ... le_id=8512

[gfb107]

Bug Report: Related to my earlier post today about an error when opening an OCAP file, I modified the RDF as suggested and RMIR now downloads from the extended remote correctly, but it simply ignores the matching IR file when I try to open it in RMIR.

Help?

For this case you should post rmaster.err for Greg.

xnappo

http://www.hifi-remote.com/forums/dload ... le_id=8512

Hmm, it loads OK for me. Might help if I had exactly the same RDF as you do.

[Capn Trips]

I tried it with EXACTLY the RDF in xnappo's Sourceforge distribution (I just downloaded and replaced mine) for 3A333A33 OCAP (Silver).

I get the VCR/1800 issue that I described earlier today, and after acknowledging, I get no change to the RMIR displays.

After applying that correction to the RDF referred to earlier (replacing the [DeviceTypeAliases] section), I now do not get the VCR/1800 setup code rejection pop-up, but I still get no change to the display.

I've tried re-booting, and still no joy.

Is the err file telling you that it loaded correctly?

[xnappo]

Is the err file telling you that it loaded correctly?

I have no idea if this is a critical error, but there is this in the log:
Opening C:\JP1\Capn Trips HT setup\Burke_Fam_Rm_OCAP\FamRm OCAP WIP.ir, last modified 12/31/09 11:21 AM
ERROR: ButtonMap 0 includes unknown keycode $f1, Creating button!
Remote is Atlas OCAP URC-1056 JP1.3 (Silver) extender
ERROR: ButtonMap 0 includes unknown keycode $30, Creating button!
ERROR: ButtonMap 0 includes unknown keycode $18, Creating button!
Warning: Shape defined for unknown button Paly
DeviceUpgrade.importRawUpgrade

Are you using the maps from the zip file? I ask because I don't see the misspelled 'Play' as 'Paly' anywhere. There is certainly more checking to do on my part here which I will do tonight.

xnappo

[gfb107]

There wasn't enough info in the err file for me to figure out what was going wrong, so I had to reproduce error. At first I couldn't get it to fail because I was using the RDF for extender v2.10. But when I switched to the RDF included in the distribution that doesn't specify a version number in the file name, but has v0.02, I finally reproduced the error. So now I can make some progress.

I looked at your IR in IR 8.02, and there are some oddities.

1. IR doesn't prompt me to choose the RDF, but shows me extender v0.02 in the title bar, so it must the using the same RDF that causes the error in RMIR
2. On the Macro tab, I see macros assigned to Key199, Key200, and Key201. According to that RDF, those are keys X_CBL, T_CBL, and V_CBL, which aren't allowed to have macros assigned to them. This is a clear indication that the wrong RDF is being used.

So the question remains: What version of the extender is actually installed in your remote, and where is the matching RDF?

Clearly RMIR needs to handle situations like this more gracefully, but given the fact that the IR file and RDF don't match it isn't surprising that RMIR falls down.

I have no explanation for the fact that downloading directly from the remote works correctly, other than wondering if the .IR file actually matches what is in the remote.

[xnappo]

The Atlas OCAP extender RDFs are very confusing. I really need to talk to Bill to see what we should do there. The problem is that early on he wasn't using the versioning so it would match the RDF to the wrong extender version. I kinda think everyone should move to 2.10 for the Atlas, but I know that is painful if you already have stuff working.

xnappo

[Capn Trips]

OK thanks. I'll have to sort out what I've done, since I've lost track since I started all of this. I'll try to get to it later this evening.

Sorry to cause so much trouble.

[gfb107]

I think I've spotted the error in the RDF (no version in the file name, v0.02 on the Name= line.

Code: Select all

EepromSize=$1400
UpgradeAddr=$0402..$0BFF
AdvCodeAddr=$0C00..$19FF

According to the RDF, the AdvCodeAddr range extends beyond the end of the EEPROM. Seems to me this has come up before.

I can add code to check for situations like this. I guess Vicky's RDF validation tool doesn't?

Anyway, using

Code: Select all

AdvCodeAddr=$0C00..$13FF

allows RMIR to load the IR file. BTW this matches the v2.10 extender RDF

[xnappo]

Okay, so the RDF in the zip file is horribly out-of-date.

Again I really need to get with Bill to figure out what to do here. I did not add any RDFs from his extenders, but neither did I delete any.

I think I need to either remove them all, or add them along with all of the versions...? I really think it would be best to have them with the other RDFs so they can be automatically enhanced fixed as we find more out about protocols and enhance Vicky's tool..

xnappo