URC-6440/OARUSB04G Extender 1.04 now available

[mathdon]

The number of users confined to 1.6 can probably be counted on the toes of one hand (no spelling mistake!).

Perhaps the thumbs of one hand, but not the toes. The number is at least one. Me! I hate upgrades, they nearly always mess something up, so I only do them when forced.

I am in correspondence with Marcin about this.

[Barf]

The number of users confined to 1.6 can probably be counted on the toes of one hand (no spelling mistake!).

Perhaps the thumbs of one hand, but not the toes. The number is at least one. Me! I hate upgrades, they nearly always mess something up, so I only do them when forced.

By "confined to" I mean "cannot update", not "do not like to update". Just for my interest, may I politely ask if are you really "confined to 1.6" in the sense of "cannot update". And if so, why.

[mathdon]

No, I meant "do not like to". The "why" is a bit strange. Some time ago I tried to compile the RMIR code under Java 7 and it gave a lot of errors, so I moved back to Java 6. After correspondence with Marcin I tried again today and it compiled without error. So unless some problem arises with the new compilation, RMIR v2.04 will be on Java 7. More specifically, compiled with JDK 1.7.0_79.

[3FG]

Graham,
Some time ago, after I started using Java 7, I made the necessary changes to the RMIR source code so that it wouldn't generate errors using either 6 or 7. I think that I asked you at that time if it was OK to check the revised code into SourceForge. In any case, I did check in the revisions.

BTW, RMIR also builds using Java 8 using 64 bits.

[yaworski]

OK, I've committed the code based on @tidklaas' patch.

@tidklaas: can you update your working copy and test if it still works for you? I've tested it on my system (Arch Linux) and it works.

---edit---

Sorry, the commit wasn't successful. I'm getting a permission error when trying to commit.

---edit---

It seems SF.net has some technical problems right now. I'll commit when it comes online again.

[yaworski]

SF.net is online at last. I've committed everything now.

[tidklaas]

@yaworski: I pulled the latest commit from Sourceforge and it still works on my system (Debian testing/stretch, Openjdk-1.8).

Thanks for fixing my fix and getting it into RMIR.

[joshtx]

I tried to copy over the extender settings.bin to my remote, but I got an error saying "The Finder can't complete the operation because some data in Settings.bin can't be read or written (Error code -36)". I get this error every time I try to write any Settings.bin file to the remote.

I just got a OARUSB04G and ran into the same problem on OSX (10.11.6). I finally got it to work by copying it from the command line (using Terminal) instead of with Finder. The key is to use the -X (do not copy extended attributes) flag with the cp command.

Open Terminal
Identify the name of the remote drive by typing in (followed by Enter):

Code: Select all

ls -l /Volumes/

(it should be obvious which one is the remote - on my system it is VOXX4REMOTE).

Assuming you downloaded and extracted the extender zip file (double click it) in your Downloads folder, you would use the following command to copy the extender to your remote:

Code: Select all

cp -X ~/Downloads/OARUSB04G\ Extender\ v1.04/Settings_reset_OARUSB04G_extender104\(2576A1\).bin /Volumes/VOXX4REMOTE/settings.bin

(you will need to adjust the path to the extender file if you have a version other than 1.04, or extracted the files somewhere else).

Assuming you get the paths correct, you should have no problem copying the settings.bin to the remote.

[bobocher]

I have a problem with one device, which works in unextended remote but doesn't work with extender.

When I setup the (unextended) remote via simpleset.com the device works. Then I import the settings into RMIR and I can edit them and save back into (unextended) remote and the device works too.

However if I install extender into the remote (via the procedure described in the extender manual) the device stops working. Other devices continue to work. Only this one doesn't want.

I have also tried the other way. After loading of (unextended) working remote into RMIR I saved the device upgrade (NEC1 protocol) into a separate file. Then I installed the extended configuration which I was using in the past. At that step I can confirm that the remote works in extended mode with multiple devices flawlessly. Now in RMIR I create a new device and import device upgrade saved on previous step. After uploading the config into remote that device doesn't work; all others work.

I tried learning a key. It was learned OK but then I can't load the settings.bin into RMIR as it complains about not being able to parse the file.

So I guess my question is: have I encountered a phenomenon or is this a known issue that certain devices don't work with extender?

[mathdon]

No, this is not a known problem. Please post files for me to be able to investigate further. I suggest posting, in a single zipped package:

• The .rmir file of the unextended remote that works and includes the problem device.
  The saved device upgrade, which will be a .rmdu file.
  The .rmir file of the extended remote without the problem device.
  The .rmir file of the extended remote after importing the device upgrade.
  The settings.bin file that RMIR says it cannot parse.
  The rmaster.err file (which you find in your RMIR installation folder) after a failed attempt to load that settings.bin file. You have to close RMIR after the failed upload before opening/copying the rmaster.err file.

This is a lot of files but I think, from your post, that they are all ones that you already have. Also, what OS are you using, and what version of Java (and is it 32-bit or 64-bit Java)?

I am asking for a lot of information as I cannot imagine what might be causing this strange behaviour.

[bobocher]

No, this is not a known problem. Please post files for me to be able to investigate further. I suggest posting, in a single zipped package

Uploaded into http://www.hifi-remote.com/forums/dload ... e_id=14489

When preparing the files this time RMIR was able to read the settings.bin with learned codes. In the end I was able to program the remote as I need using learned keys.

Still the original problem with device upgrade not working in extended remote persisted. I prepared all files you asked and even more, if you want to investigate this issue.

System info:

Code: Select all

RemoteMaster v2.04 build 10
System Properties:
   java.version = 1.8.0_121
   java.vendor = Oracle Corporation
   os.name = Windows 8.1
   os.arch = x86
   java.home = C:\Program Files (x86)\Java\jre1.8.0_121
   java.class.path = C:\Tools\RemoteMaster-2.04\RemoteMaster.jar

Thank you!

[mathdon]

Mystery solved! The setup code for the device causing you problems is 5328. This is the first time I have seen a setup code greater than 4095 (i.e. with more than 12 bits). Revisions R00 and R01 of the URC-6440 only support setup codes up to 4095, and consequently that applies also to the extender, which is based on R01. I see you have R02, which presumably supports setup codes up to 16 bits.

The work-around is simple. All a setup code does is create a link between the device button and the device upgrade, so RMIR allows you to change its value. Open your extender setup with the problem device in RMIR and go to the Devices tab. Select the PVR device with setup code 5328 and press the Edit button. Change the setup code to a value less than 4096 (I used 3600 in my testing as all the built-in setup codes in the extender are less than this) and press OK.

Go back to the General tab and check that the value 5328 has been changed there, too. If it hasn't, then double-click that value to edit it and change it to whatever you used on the Devices tab. This step shouldn't be necessary as it should have changed automatically, but it is worth checking.

Save the modified setup and upload it to your remote. All should now work OK.

I haven't looked into the learned signals issue as it seems to have been a one-off glitch. If you still have problems with it, post again and I will investigate further.

[bobocher]

Amazing support, Graham!

I'll try the workaround and write back.

Since I couldn't find device upgrade files for my new PVR as rmdu file, I used simpleset.com. It asked to upload my existing settings.bin but of course didn't like my extended settings file. Then I used the "reset remote" function of the web-site which gave me fresh settings.bin, which I then uploaded back to the site and added my PVR on the site. So I guess R02 came with the reset settings.bin from simpleset.com and wasn't initially on my remote.

I've just tried again reseting via web site and opened that file in RMIR and it shows R02.

Then I tested adding new devices on simpleset.com. Added Samsung TV and opened the file in RMIR - two devices with codes above 4095. Added
Sony TV - four devices with codes above 4095.

Added Panasonic TV - RMIR cannot load the file. The file and the RMIR log posted here - http://www.hifi-remote.com/forums/dload ... e_id=14490.

[mathdon]

It looks to me as if one of the device upgrades for the Panasonic TV that you downloaded from simpleset.com is corrupt. It seems to be missing its last byte. So RMIR cannot interpret it, and it crashes. But the remote doesn't attempt to interpret it unless that is the one you select. I think it has setup code 850.

If there is a setup code 850 in the Panasonic downloads, could you try it please? All I want to know is if it sends any signals, i.e. the device button lights up when you press the keys. Not all keys will have signals on them, but the number keys will, so you could try those.

[bobocher]

I'm confirming the workaround with changing setup code works with my PVR.

My setup works flawlessly now. Thanks again!


I actually don't have a Panasonic TV to perform the test. All I wanted was to do a small investigation for you to find out how many devices are affected by setup codes above 4095. For that purpose I took fresh settings.bin from simpleset.com and then uploaded it back to the site and added Samsung TV, saved settings.bin and opened it in RMIR. Then I did the same for Sony TV and then for Panasonic TV. The last test failed.

I've just repeated the test with Panasonic with the same result, so it wasn't a temporary glitch of simpleset.com.

I leave it to you to decide whether it is worth investigating or not. As I've said thanks to your help my setup works perfect at this moment.

More results:
LG TV - 7 devices with setup code above 4095;
Sharp TV - 1 device with setup code above 4095;
From previous test:
Samsung TV - 2 devices with setup code above 4095;
Sony TV - 4 devices with setup code above 4095;