URC-6440/OARUSB04G Extender 1.04 now available

[tidklaas]

Well, apparently it had something to do with OSX or my MacBook. After trying everything I could think to with the MacBook short of formatting the remote, I booted up my old XP box to give that a shot. Worked first try, and the remote seems to be functioning again. Phew!

This echoes my experience trying to install the extender on my OARUSB04G 4000 from Linux. Every time I tried to copy Settings_reset_OARUSB04G_extender104(2576A1).bin over the settings.bin on the remote, I got drive errors in the system log and the remote was soft-bricked. Recovering required the "plug in USB and only then put in batteries" trick that forces it to mount the settings drive without trying to read the (invalid) settings file.

[...]

I ran into the same problem using Linux. Apparently Simpleset's FAT implementation is rather... simple (sorry, could not resist) and can not handle blocks being written out of order. A workaround is using 'dd' instead of 'cp' and forcing it to perform block writes synchronously:

Code: Select all

dd bs=512 conv=notrunc,fsync oflag=sync of=<path/to/remote>/OFA\ REMOTE/settings.bin if=YourSettings.bin

Tido

[yaworski]

@tidklaas that's a great find. I can confirm that it's also working on my system.

As for the FAT/mass storage implementation in the remote it's more complicated than it seems because the file is also being decrypted before writing into flash so the remote's CPU has some work to do.

I wonder if there's a way to duplicate this behaviour in Java. Saving the file in RMIR to temporary location and then calling Runtime.exec to execute dd would probably work but it's not very elegant solution.

[tidklaas]

I wonder if there's a way to duplicate this behaviour in Java. Saving the file in RMIR to temporary location and then calling Runtime.exec to execute dd would probably work but it's not very elegant solution.

I am no expert on Java, the last time I was forced to use it I was still in university. In C this would be equivalent to opening the file on the remote with flags O_WRONLY|O_SYNC and then writing the image in 512 byte portions.

Tido

[tidklaas]

Okay, after patching RMIR to write the config image with synchronous I/O and in 512 byte blocks, I can upload directly to my URC-6440 R02.

Since SF will not let me post a patch for the project, I will just append it here. If anyone takes offence at the coding style or methods used, please bear in mind that I mostly do kernel level or bare metal development in C and have not touched Java in over ten years...

Code: Select all

Index: km/com/hifiremote/jp1/RemoteMaster.java
===================================================================
--- km/com/hifiremote/jp1/RemoteMaster.java     (revision 1482)
+++ km/com/hifiremote/jp1/RemoteMaster.java     (working copy)
@@ -3346,6 +3346,7 @@
     if ( ioName.equals( "JPS" ) )
     {
       JPS jps = ( JPS )ioIn;
+/*      
       if ( use == Use.UPLOAD && osName.equals( "Linux" )
           && ( portName == null || portName.contains( "REMOTE" ) ) )
       {
@@ -3354,7 +3355,9 @@
         JOptionPane.showMessageDialog( this, message, title, JOptionPane.INFORMATION_MESSAGE );
         return null;
       }
-      else if ( jps.isOpen() && ( use == Use.SAVING || use == Use.SAVEAS ) )
+      else 
+*/
+      if ( jps.isOpen() && ( use == Use.SAVING || use == Use.SAVEAS ) )
       {
         portName = jps.getFilePath();
         System.err.println( "Already open on Port " + portName );
Index: km/com/hifiremote/jp1/io/JPS.java
===================================================================
--- km/com/hifiremote/jp1/io/JPS.java   (revision 1482)
+++ km/com/hifiremote/jp1/io/JPS.java   (working copy)
@@ -5,12 +5,15 @@
 import java.io.File;
 import java.io.FileInputStream;
 import java.io.FileNotFoundException;
-import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
-import java.io.OutputStream;
+import java.nio.ByteBuffer;
+import java.nio.channels.FileChannel;
+import java.nio.file.Paths;
+import java.nio.file.StandardOpenOption;
 import java.util.Arrays;
+import java.util.EnumSet;
 import java.util.List;
 
 import javax.swing.JOptionPane;
@@ -313,10 +316,23 @@
     }
     try
     {
+      int written, remain;
       ByteArrayOutputStream bao = new ByteArrayOutputStream(); 
-      s.save( bao ); 
-      OutputStream o = new FileOutputStream( filePath ); 
-      o.write( bao.toByteArray() );
+      s.save( bao );
+      FileChannel o = FileChannel.open(Paths.get(filePath), EnumSet.of(StandardOpenOption.WRITE, StandardOpenOption.SYNC));
+      
+      written = 0;
+      remain = bao.size();
+      while(remain > 0){
+        int chunk = Math.min(512, bao.size() - written);
+        
+        ByteBuffer buff = ByteBuffer.wrap(bao.toByteArray(), written, chunk);
+        o.write(buff);
+        
+        remain -= chunk;
+        written += chunk;
+      }
+
       bao.close();
       o.close();;
     }

Tido

[yaworski]

@tidklaas this is great. I'll review the patch and if it's OK I'll submit it to SF.

[yaworski]

@tidklaas: For some reason the patch couldn't apply cleanly. I've made the changes manually with some modifications. For some reason java.nio method doesn't work properly on Windows - the upload process takes a really long time and data uploaded are corrupted. I don't know how it would behave on OS X. I've added a check so the java.nio is used only on Linux and old way is used otherwise.

I can't yet commit that change to the repo though because java.nio requires Java 1.7 and RMIR right now uses 1.6+.

[tidklaas]

@yaworski: for me this patch is just a proof of concept, so I have no problem with it being modified or even completely rewritten.
As I said, I have hardly any knowledge of proper Java coding. I just cobbled this thing together with the first interfaces I could find that looked like they were doing what I wanted.

[Barf]

java.nio requires Java 1.7 and RMIR right now uses 1.6+.

So why not update? (IrScrutinizer uses 1.7, and there are quite some niceties there). Graham?

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

[yaworski]

@Barf, I've already PM-ed Graham asking about this and I'm waiting for his response before moving forward with committing changes to the repo.

@tidklaas, you've done a really good job anyway :).

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