UEI Learning format change

[The Robman]

As far as I can tell, I have resolved the latest lot of bugs found in Vyrolan's code.

Thanks Graham, I will try to test this all as soon as possible and report back.

None of the Suppress Messages options were intended to suppress confirmation messages. They only do what their names, and tooltips, say. I have added a new option that will suppress these. It won't suppress all the confirmation messages as I think some are important, so if you find any others that you think it should suppress, let me know.

Will do, and another thing that I just remembered. There are several pop-up messages in RM that say you can suppress them using that option, but that option doesn't exist in RM, it's only in RMIR, and the RMIR setting doesn't affect RM.

Anyway, when I repeated and clicked Upload, RMIR just crashed. So I restarted it and downloaded again to see if the learns were still present and they are.

That is nothing to do with the Delete All button, it is to do with the upload crashing and that is caused by driver problems. See the thread RemoteMasterv2.04 crash on upload to device for information on how to install the WinUSB driver so that it works on Windows 8.1 and later. I have just re-tested this with my URC-8550 and a cable with a Delcom chip and have done both a download and upload without issue.

Yeah, I know it's not related, I didn't mean to imply that it was, just that I found it while trying to test Delete All. I'm using Windows 7 (64 bit), so I didn't think the Windows 8.1 update applied to me. Should I try it none the less?

[The Robman]

Anyway, when I repeated and clicked Upload, RMIR just crashed. So I restarted it and downloaded again to see if the learns were still present and they are.

That is nothing to do with the Delete All button, it is to do with the upload crashing and that is caused by driver problems. See the thread RemoteMasterv2.04 crash on upload to device for information on how to install the WinUSB driver so that it works on Windows 8.1 and later. I have just re-tested this with my URC-8550 and a cable with a Delcom chip and have done both a download and upload without issue.

Yeah, I know it's not related, I didn't mean to imply that it was, just that I found it while trying to test Delete All. I'm using Windows 7 (64 bit), so I didn't think the Windows 8.1 update applied to me. Should I try it none the less?

Ok, I read that entire thread but I'm still not clear what I am supposed to do. I tried to follow this guide where, as expected, I didn't have "Universal Serial Bus devices" available, so I went onto the next step where it ways to edit the following registry: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\<VID_vvvv&PID_pppp>" but when I went there, I had 100s of entries that match that pattern, so I have no idea which one I'm supposed to edit.

[3FG]

The Delcom USB JP1 interface uses VID 0FC5, PID 1222

[mathdon]

I'm using Windows 7 (64 bit), so I didn't think the Windows 8.1 update applied to me. Should I try it none the less?

I'm not an expert on the communication stuff. My understanding is that the WinUSB installation instructions in the Tools > Drivers file section cover Win 7 and that the link I posted covers the later Windows versions, but 3FG is the expert on this. We have certainly had users successfully install the WinUSB driver on all Windows versions and be able to do both uploads and downloads with it and a Delcom cable, so your issues with it should be solvable.

[The Robman]

The Delcom USB JP1 interface uses VID 0FC5, PID 1222

Thanks Dave, so I have 2 entries under that, one called 6&e72cee4&0&1 and another called 6&e72cee4&0&1, both have the correct GUID {cafa8e93-7c32-4c27-b088-d8c36aaf4ebf} under Device Parameters > DeviceInterfaceGUIDs

I just re-checked RMIR in case I had accidentally fixed it, but it's the same, it can download but cannot upload. Then I re-checked IR.exe, it can still download and upload.

That's the part that I just don't get, if it works for IR.exe, doesn't that confirm that I have the right driver and it's installed correctly? Why does it work for one program and not the other?

[mathdon]

Might the difference between the behaviour of RMIR and IR be related to IR being a 32-bit program and RMIR is essentially a 64-bit one (assuming you are using 64-bit Java)? As I said, I don't understand the communication stuff, so that idea could be nonsense but it is one difference between them.

[The Robman]

Graham, I just did some testing and the null pointer stuff definitely seems to be fixed. I'm not seeing my settings on the Timing Summary screen preserved though. When I bring up the screen, I switch it to Analyzed mode, enter 300 and select ODD, then I click OK to close it, and then when I re-open it again, it has gone back to Raw mode and if I re-select Analyzed, I have to re-select ODD and re-enter 300. It would be nice if it stayed on Analyzed and had the entries pre-populated.

Another oddity is, using that same test file that I was using before, if I edit the malformed button and set it to use 300 and ODD, and then go to the Raw/Summary, the 300 is carried over. Then if I go back and click Unlock, then go back to Raw/Summary, it's still shows 300. The only way to get it back to the real raw time is to change the 300 to 1 in the edit screen. What's odd though is that if I enter 300 for one of the other learned buttons, it doesn't carry over to Raw/Summary.

I'm reporting this just for completeness, I think this build is good enough for general release. Thank you for taking the time to listen and build in my suggestions.

[mathdon]

if I re-select Analyzed, I have to re-select ODD and re-enter 300. It would be nice if it stayed on Analyzed and had the entries pre-populated.

That is what was supposed to happen. My mistake, I left in some lines I put in for testing and intended to delete, that had the effect of overwriting part of the "fix". I'll post a build 7 that should work as intended.

Another oddity is, using that same test file that I was using before, if I edit the malformed button and set it to use 300 and ODD, and then go to the Raw/Summary, the 300 is carried over.

I can't reproduce this, either with build 6 or the forthcoming build 7. It may have been a side effect of the lines I should have deleted that only happened in circumstances I am not reproducing. If it still happens in build 7, let me know.

[The Robman]

Here's some screen shots, in case it helps. Hopefully they are self-explanatory, but I can do a write-up if needed.

https://www.hifi-remote.com/forums/dload ... e_id=14734

[mathdon]

I haven't had time to look at your screenshots yet, but I have, since the previous post, discovered other odd behaviour with the Round To box and the Unlock button which is probably related to what you see. I need to sort that out before I post a build 7.

[mathdon]

Rob, now I've seen your screenshots, I understand better what you mean and I can reproduce it. In a sense it isn't a bug, it is a curious but intended behaviour. However, it is so strange and unexpected that I am trying to make it behave more naturally in the circumstances. The problem really is that there are so many settings in this code of Vyrolan that interact with one another that it is difficult to make all combinations behave in the way one might expect. I'll do my best, but in the end we may have to put up with something less than perfect.

[The Robman]

That's totally fine Graham, like I said, this build is good enough for release "as is", I was just highlighting some oddities.

If it were up to me, the "raw" panel would be just that, it would be raw with no timing adjustments at all, and all the editing would occur on the analyzed panel (both bi-phase and regular).

[The Robman]

Curiosity question Graham, but why does RMIR not let you create "new" images for newer remotes like the Nevo? And why could I not open the raw download files that vbs posts here?

If it's not feasible to have RMIR create a valid file for those remotes from scratch, would it be possible to include a basic rmir file for each of them in the distribution that we could use instead?

There are often occasions where I want to re-create what someone is describing, but I don't have their remote and RMIR won't let me create a generic file, so I am unable to.

Also, when I was looking at the functions list in the rf_good.rmir file that vbs posted, I tried to widen the hex column so that I could see all 3 bytes but it wouldn't let me.

Speaking of 3-byte protocols, it occurs to me that the EFC5 column is completely useless for executors that use more than 2 bytes, so we should probably kill it in such cases. I can see some value to keeping the regular EFC column, but there probably should be a way in protocols.ini to tell it which column it affects. For example, in my new Onkyo Combo executor, the OBC is in the 2nd byte, so you'd want any change to EFC to affect that byte. Might be good to also have the option in protocols.ini to kill the EFC column if you know in advance that it makes no sense to use it.

[mathdon]

New images are only possible for remotes where the RDF contains enough information to create a minimal setup. This is not the case with the Nevos and similar. There are lots of .rmir files for Nevos available in the forum, so I see no need to include one in the distribution.

You can't open a raw download from a Nevo, or any remote with segments, because the E2 area that is downloaded in a raw download does not contain the signature, or any other information that would allow RMIR to identify the remote.

I may look at your other points when I have time.

[The Robman]

New images are only possible for remotes where the RDF contains enough information to create a minimal setup. This is not the case with the Nevos and similar. There are lots of .rmir files for Nevos available in the forum, so I see no need to include one in the distribution.

I would counter that trying to find a clean rmir file for each of those remotes is not that easy, so it would be much better for someone to do that work once, presumably at the time the new RDF is created, and include the files in the distribution. This is all about giving experts, who don't have the remote in question, all the tools they need in order to help folks.

You can't open a raw download from a Nevo, or any remote with segments, because the E2 area that is downloaded in a raw download does not contain the signature, or any other information that would allow RMIR to identify the remote.

Then could I suggest that you include the bare minimum info in the raw download? I tried building a new rmir file using one from another remote as a template, but could never get it to work.

I may look at your other points when I have time.

No rush, I'm just posting thoughts as they come to me, as I have your attention.