Forum for JP1 remotes
http://www.hifi-remote.com/forums/
I don't knowAndrewZ wrote:can I use LKP on Device buttons as an alternative to Activity buttons? Is this supported by the Extender?
. It isn't deliberately supported, but RMIR will allow you to set one up. I just don't know if it will actually work. I have a feeling that it won't work but there is no harm in you trying it to see, though. In the RMIR setup for an LKP you would need to set Device to "<None>" and Key to the device key concerned.
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.macro wrote: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!
Code: Select all
[993488.681515] usb 1-2: new full-speed USB device number 32 using xhci_hcd
[993488.871024] usb 1-2: New USB device found, idVendor=06e7, idProduct=8020
[993488.871032] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[993488.871036] usb 1-2: Product: UEI Mass Storage
[993488.871040] usb 1-2: Manufacturer: UEI Remotes
[993488.871044] usb 1-2: SerialNumber: 000000000001
[993488.872254] usb-storage 1-2:1.0: USB Mass Storage device detected
[993488.873247] scsi host65: usb-storage 1-2:1.0
[993489.871246] scsi 65:0:0:0: Direct-Access PQ: 0 ANSI: 0
[993489.872240] sd 65:0:0:0: Attached scsi generic sg1 type 0
[993489.873594] sd 65:0:0:0: [sda] 465 512-byte logical blocks: (238 kB/233 KiB)
[993489.874480] sd 65:0:0:0: [sda] Write Protect is off
[993489.874489] sd 65:0:0:0: [sda] Mode Sense: 03 00 00 00
[993489.875358] sd 65:0:0:0: [sda] No Caching mode page found
[993489.875369] sd 65:0:0:0: [sda] Assuming drive cache: write through
[993490.001472] sda: sda1
[993490.001476] sda: p1 size 465 extends beyond EOD, enabling native capacity
[993490.127431] sda: sda1
[993490.127441] sda: p1 size 465 extends beyond EOD, truncated
[993490.132183] sd 65:0:0:0: [sda] Attached SCSI disk
[993495.160848] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[993495.186024] sd 65:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[993495.186034] sd 65:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
[993495.186039] sd 65:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
[993495.186046] sd 65:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 00 00 01 00 00 01 00
[993495.186050] blk_update_request: I/O error, dev sda, sector 1
[993495.186056] Buffer I/O error on dev sda1, logical block 0, lost sync page write
[993568.007842] sd 65:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[993568.007846] sd 65:0:0:0: [sda] tag#0 Sense Key : Illegal Request [current]
[993568.007848] sd 65:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
[993568.007850] sd 65:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 00 00 00 02 00 00 03 00
[993568.007852] blk_update_request: I/O error, dev sda, sector 2
[993568.007855] Buffer I/O error on dev sda1, logical block 1, lost async page write
[993568.007858] Buffer I/O error on dev sda1, logical block 2, lost async page write
[993568.007859] Buffer I/O error on dev sda1, logical block 3, lost async page write
[993568.021901] VFS: Dirty inode writeback failed for block device sda1 (err=-5).
[993589.017643] usb 1-2: USB disconnect, device number 32
Sorry, no, this is not possible. It is possible to control the length of time that a key press in a macro is held, see the section "Special buttons for macro control" in the extender manual, but the timing range is 0 to 450ms which is probably too short to be recognised as a long keypress. This facility was added to allow users to shorten, rather than lengthen, the default time of 250ms as for some equipment 250ms causes a repeat action to start. Also, if you keep pressed the key that sends the macro, the last key in the macro sequence is effectively held until you release the macro key. However, this won't help for anything other than the last key.bobocher wrote:Is it possible to simulate a long key press, in particular as part of a macro?
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:Elemecca wrote: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.macro wrote: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!
[...]
Code: Select all
dd bs=512 conv=notrunc,fsync oflag=sync of=<path/to/remote>/OFA\ REMOTE/settings.bin if=YourSettings.bin
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.yaworski wrote: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.
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();;
}
So why not update? (IrScrutinizer uses 1.7, and there are quite some niceties there). Graham?yaworski wrote: java.nio requires Java 1.7 and RMIR right now uses 1.6+.