RMIR: Prototype IR function in RM

[mathdon]

I actually wanted to see what's in this remote. What I got is General tab ok, then all the others are empty till Devices. There is no protocol number, so on the protocols tab I have no clue (well, a little) which device protocol goes with what device. I did not open .ir file, that's not the point of this exercise.

IR file I just downloaded from 8910
http://www.hifi-remote.com/forums/dload ... le_id=8876

Liz, since you posted the .ir file, I have been able to diagnose the problem. It was a faulty entry in protocols.ini. Here is a version of protocols.ini with the faulty entry commented out. With this I can open your .ir file and save it as a .rmir one. Please use it to try your downloading again.

I tried 4 remotes and I could download from them all, but since I couldn't save I sure didn't want to try to upload.


10820N even with a 981 JP1.2

Comcast 1067A JP1.2
Comcast 1067B JP1.3
URC7800 JP1

Vicky, if you post .ir files from these remotes I will try to diagnose them too.

[vickyg2003]

I tried 4 remotes and I could download from them all, but since I couldn't save I sure didn't want to try to upload.


10820N even with a 981 JP1.2

Comcast 1067A JP1.2
Comcast 1067B JP1.3
URC7800 JP1

Vicky, if you post .ir files from these remotes I will try to diagnose them too.

Well I opened my IR files and they save in rmir just fine. Its only when I start with a download, that the RMIR can't be produced, so I'm a little unsure if you want my IR file, or do you want a raw download IR file? There doesn't seem to be any indication in the log file that any error is being generated when I save, it creates a file, there is just nothing in it. I have Tommy's JP1.2/1.3 and my parallel cable plugged in and I'm running on windows 2k. Everything looks good on the screen,after the download. You save it, and the file is created. Its just empty.


Problems:
Save and Save/As "after download" isn't working produces an empty file instead of current image.

Save shouldn't be available after download, since it overwrites the last RMIR without warning.

Devices numbers are not being updated after an import, until you reset focus.

Assign Device number message is popping up at the wrong time. It should pop up when you add/edit the device, not after you leave the device.

[mathdon]

Well I opened my IR files and they save in rmir just fine. Its only when I start with a download, that the RMIR can't be produced, so I'm a little unsure if you want my IR file, or do you want a raw download IR file?

They shouldn't be different. If they are, then it is interesting in itself, as it means that IR.exe is silently "correcting" something - which it unfortunately has a habit of doing. So if they are different, or if you are not sure that they are the same, could I have both, please? I really would like to get to the bottom of this curious behaviour.

I'll look into your other issues as well.

Edit: Vicky, ignore the first paragraph. I realised that I have never actually tried saving after a download, so I just did so. I get an empty file, too. Will sort it out.

[ElizabethD]

Liz, since you posted the .ir file, I have been able to diagnose the problem. It was a faulty entry in protocols.ini. Here is a version of protocols.ini with the faulty entry commented out. With this I can open your .ir file and save it as a .rmir one. Please use it to try your downloading again.

The protocols.ini change permits to download from 8910
Results:
General tab - ok
Keymoves - 33 of 59 are missing/hidden in upgrades
macros - ok
Special - ok
FAV - ok
devices - ok - I still would like to see protocol ID as one of the columns here
Protocols - 2 missing/hiding: 00CD is a modified Panasonic 2-byte job, identifies as Denon-K, but that's ok, we've discussed it ages ago. The other one is XMP 016c.
I clicked on the RCVR setup 2022, the Panasonic amp, and to my total surprise I see that all OBCs are goofy, all >255. Yes, there's a pattern what gets added, these are not random numbers, but that's not how we code things. Hex values look ok.
Saving - saved file is 0 bytes, so that is an issue. 0 bytes still after exit from RMIR and refreshing of the explorer list.

Edited: In case needed - RMIR log
http://www.hifi-remote.com/forums/dload ... le_id=8886

[vickyg2003]

Well I opened my IR files and they save in rmir just fine. Its only when I start with a download, that the RMIR can't be produced, so I'm a little unsure if you want my IR file, or do you want a raw download IR file?

They shouldn't be different. If they are, then it is interesting in itself, as it means that IR.exe is silently "correcting" something - which it unfortunately has a habit of doing. So if they are different, or if you are not sure that they are the same, could I have both, please? I really would like to get to the bottom of this curious behaviour.

I'll look into your other issues as well.

Edit: Vicky, ignore the first paragraph. I realised that I have never actually tried saving after a download, so I just did so. I get an empty file, too. Will sort it out.

Well I did this before I read that you hadn't saved. However I did a RAW download and a regular download and RMIR can't open the RAW IR file, so there are two things going on with this remote.
nosave.zip has the two IR files, the one that doesn't open and the one that does, as well as the RM error log.

[mathdon]

I've found the source of the empty saved files after a download. The correction (one line) will be in the next batch that I upload to SourceForge for Greg. It was a simple oversight when Greg introduced, recently I think, Device Button Notes.

Will explore the other issues later.

[mathdon]

I clicked on the RCVR setup 2022, the Panasonic amp, and to my total surprise I see that all OBCs are goofy, all >255. Yes, there's a pattern what gets added, these are not random numbers, but that's not how we code things. Hex values look ok.

They are in fact how Denon-K codes things. If you look at DecodeIR.html you will see that Denon-K uses 12-bit OBCs coded as lsb comp.

Take key 0, for example. Hex = DF 67. In binary this is 11011111 01100111. Reversing this and taking the complement (as lsb comp) gives 00011001 00000100. It's a 12-bit OBC so only the first 12 bits are actually function code, i.e. 000110010000, or in hex, $190. In decimal this is 400 as given in the OBC column.

[mathdon]

Save and Save/As "after download" isn't working produces an empty file instead of current image.

Dealt with (for the next version), see earlier message.

Save shouldn't be available after download, since it overwrites the last RMIR without warning.

I've dealt with this, too.

Device numbers are not being updated after an import, until you reset focus.

I can't reproduce this, but I am working with my development version and I think it is related to a bug that I have already fixed. I won't do anything more but would like you to test again once Greg has released a new version.

Assign Device number message is popping up at the wrong time. It should pop up when you add/edit the device, not after you leave the device.

The behaviour I have is exactly as in IR.exe. This too may have changed as a result of the bug fix I've just mentioned, so again please test when there is a new version to see if the behaviour is then as you think it should be.

I did a RAW download and a regular download and RMIR can't open the RAW IR file, so there are two things going on with this remote.

RMIR saw a base address of 0000 in the RAW IR file, which did not agree with the value EC00 in the RDF, and treated this as an error. I've amended this so it just prints a message in the error log and continues. Your raw file now loads.

[mathdon]

Protocols - 2 missing/hiding: 00CD is a modified Panasonic 2-byte job, identifies as Denon-K, but that's ok, we've discussed it ages ago. The other one is XMP 016c.

Hidden but not missing. In the Devices tab, double click on an entry (or one click and press Edit) to get the device and its protocol in full detail. XMP 016C shows up for the device Cable 1982. The Protocol tab in RMIR only shows protocols that are not assigned to devices.

[vickyg2003]

Graham, thanks for the prompt attention to my issues.

Protocols - 2 missing/hiding: 00CD is a modified Panasonic 2-byte job, identifies as Denon-K, but that's ok, we've discussed it ages ago. The other one is XMP 016c.

Hidden but not missing. In the Devices tab, double click on an entry (or one click and press Edit) to get the device and its protocol in full detail. XMP 016C shows up for the device Cable 1982. The Protocol tab in RMIR only shows protocols that are not assigned to devices.

I've got a lot of upgrades that use custom protocols. For these protocols "01FF" is often used for 'one-of' type custom protocols. I added three different devices that use 01FF as the protocol. This seems to be hidden from me. How would a person deal with this, since you never see the protocol ID?

One of the first things I do when looking at someone's IR file is to make sure that the device calls the appropriate protocol and that there is only one protocol with the name. How do I do this kind of testing with RMIR? It seems like this new "hide everything from the user" approach is going to make diagnosing things very difficult.

[The Robman]

There has been a lot of "back and forth" conversation between the RMIR developers and the rest of us about what should be in RMIR, where the developers seem to be in agreement that the "tie all the parts together" approach is the way to move forward, and most of the actual users seem to be saying "stop hiding everything from me".

So here's how I think things need to proceed.

The first official release of RMIR should do, or at least it should try to do, everything that the current IR can do, which means, show all of the protocols in the Protocols tab and show all of the keymoves in the Keymoves tab. In addition to that, RMIR can still do things that IR can't do, such as incorporating protocols and/or keymoves into the upgrade display.

Sure, this means that keymoves may be displayed in two places, likewise for protocols, but that's OK. In fact, I think it's the only way we can move forward with this, because without it, you'll never get IR users to switch over, at least not the experts.

[mathdon]

I have committed my recent work to SourceForge. It is now up to Greg how to proceed.

[ElizabethD]

I clicked on the RCVR setup 2022, the Panasonic amp, and to my total surprise I see that all OBCs are goofy, all >255. Yes, there's a pattern what gets added, these are not random numbers, but that's not how we code things. Hex values look ok.

They are in fact how Denon-K codes things. If you look at DecodeIR.html you will see that Denon-K uses 12-bit OBCs coded as lsb comp.

Take key 0, for example. Hex = DF 67. In binary this is 11011111 01100111. Reversing this and taking the complement (as lsb comp) gives 00011001 00000100. It's a 12-bit OBC so only the first 12 bits are actually function code, i.e. 000110010000, or in hex, $190. In decimal this is 400 as given in the OBC column.

OMG
So are you saying that when I download from my/somebody's remote perfectly good Panasonic stuff, I will have to go through the conversions from Denon-K to figure out whether it matches 8-bit OBCs I put in or found in the file section? If so, I do not like it one little bit.

Edited:Key 0 for the Panasonic upgrade I used is main device 160, subdevice 4 (that's where DF comes in), obc 25. Really, this is going to be very tough sledding if we'll have to be converting

[mathdon]

So are you saying that when I download from my/somebody's remote perfectly good Panasonic stuff, I will have to go through the conversions from Denon-K to figure out whether it matches 8-bit OBCs I put in or found in the file section? If so, I do not like it one little bit.

The problem is that there are two protocols, Panasonic Combo and Denon-K, in protocols.ini that have identical codes but different translations between hex and OBC. There is no way any software can distinguish which one is in the upgrade. RMIR identifies the first matching one that it finds in protocols.ini, which is Denon-K. So if you edit protocols.ini and move the entry for Panasonic Combo to be above Denon-K, it will find Panasonic Combo. Even if it should be Denon-K, of course .

If you do this, make sure it is a .ir file that you open in RMIR, not a .rmir file, as a .rmir file will remember what it found for that protocol last time. I've just tested this, and it works.

That said, I don't understand why you feel worse off with RMIR than you did with IR.exe on this issue. IR.exe doesn't have the ability to identify the protocol, it just gives you the PID, Hex and EFC, and a 5-digit EFC at that, while the RDF seems to indicate that remote only supports 3-digit EFCs. So you don't get the OBC at all. This is one respect in which RMIR is a lot more powerful than IR.exe.

[vickyg2003]

That said, I don't understand why you feel worse off with RMIR than you did with IR.exe on this issue. IR.exe doesn't have the ability to identify the protocol, it just gives you the PID, Hex and EFC, and a 5-digit EFC at that, while the RDF seems to indicate that remote only supports 3-digit EFCs. So you don't get the OBC at all. This is one respect in which RMIR is a lot more powerful than IR.exe.

Because with one click AT A GLANCE we could see the PID, the button, and the hex associated with that button in IR. Now the information is spread over 3 screens, and takes 5 clicks.

I now have all the information I need to switch to IRScope and see if the remote is shooting what I expect to see.