Using URC6440 and OARUSB04G Remotes with Linux
When you connect a USB remote to your computer, it connects by creating a "device" that has to be mounted. Many modern Linux distributions don't mount the URC6440 nor the OARUSB04G automatically. If yours does mount it, you will get the same response when you plug in your remote as if you plugged in a memory stick. If that's the case, you will have to take the same action (or none!) to mount the remote as you would with a memory stick. If that happens, you don't need to read any of what follows. However, some distros have withdrawn support for these remotes because the file system on them does not fully conform to standards. There is a way of forcing those remotes to mount, and once you have installed three scripts on your Linux computer, all will work!
The path of the device created is unpredictable. It may turn up as /dev/sdc1. /dev/sdd1, sde1 etc., depending on what's already connected. However, there is a "predictable" device path that is created when you plug it in, and it's the same for both the URC6440 and OARUSB04G models.
That path is: /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
It's a bit long to say the least, and not the easiest thing to remember, but it will always be the same, so we can make use of it in the mount command.
Any User Method
Due to the author's lack of knowledge, it has taken a long time to do the research on the internet to work out this method. The annoying thing is, that it was so simple to do once I got the information I needed.
Create the following script and store it under /etc/udev/rules.d with a name of your choice, such as 62-usbremote.rules -- there are two lines, by the way.
ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa &"
ACTION=="remove", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/umount_ofa &"
The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".
This next script will mount your remote. I've called it mount_ofa and it goes in /usr/local/bin. It must be owned by root and made executable: Although the mount will be owned by root, there will be read-write access to all users:
#!/bin/bash mkdir /media/REMOTE mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /media/REMOTE/ -o user,umask=0000
The -o switch means "options" and those given, user and umask=0000 will ensure that any user can access the remote.
RMIR should detect your plugged in remote automatically, but if for any reason it doesn't, you can set it up to point to it correctly from its menus:
Remote > Interface > JPS... > Other : /media/REMOTE/settings.bin
Unmounting
This next script will attempt to unmount your remote. It will run automatically when your remote is unplugged. I've called it umount_ofa and it also goes in /usr/local/bin, and must be owned by root and made executable. For reasons that I don't fully understand, sometimes it won't unmount. There's no need to worry about this, because when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug your remote from the computer once the data is transmitted:
#!/bin/bash sleep 1 umount /media/REMOTE/ sleep 1 rmdir /media/REMOTE
It includes a couple of 1-second delays to improve the chances of the remote being unmounted, and thus the folder /media/REMOTE being removed. Note that rmdir, without any switches, will only remove an empty directory. So, if by some chance, your remote is still connected and mounted, its data is safe. This means you can also use this script (though it must be run as root) to unmount the remote before disconnecting it.
This has been tested in the two Linux distributions I use, PCLinuxOS and MX Linux. I have no reason to doubt that this will work on other versions of Linux. An alternative to the /etc/udev/rules.d folder might be /lib/udev/rules.d and the two distros I mention actually use both. The thing is that there should be a rules.d folder somewhere!
One User at a Time Method (Deprecated)
This is an old method which works in single-user situations, but is more complicated and may not do so in a computer used by multiple users with separate logins. It's left here for the time being, but may be removed in the future.
The following will allow one user to get access to the remote control in order to run RMIR and communicate with the remote. If only one user is logged in that will be ok. If more than one user is logged in, (for example as a result of using "Switch User") it will select the one logged in the longest. This will be adequate in most cases.
Create the following script and store it under /etc/udev/rules.d with a name of your choice, such as 62-usbremote.rules -- it's all one line, by the way.
ACTION=="add", KERNEL=="sd*[0-9]", ATTRS{idVendor}=="06e7", ATTRS{idProduct}=="8015|8020", RUN+="/usr/local/bin/mount_ofa_setup"
The idProduct codes are 8015 for the URC6440 and 8020 for OARUSB04G, and putting a bar between them means "or".
This next script serves merely to return control to the udev system as quickly as possible, hence the & at the end of the line. I've called it mount_ofa_setup and it goes in /usr/local/bin. It must be made executable:
#!/bin/bash /usr/local/bin/mount_ofa &
This next script does the actual job. It also goes in /usr/local/bin and is called mount_ofa and must be made executable:
#!/bin/bash
hisname=`who | head -n1 | awk '{print $1;}'`
mkdir -p /media/$hisname/REMOTE
chown $hisname:`id -gn $hisname` /media/$hisname/REMOTE
mount -t vfat /dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1
/media/$hisname/REMOTE/ -o uid=`id -u $hisname`,gid=`id -g $hisname`,utf8,dmask=027,fmask=137
NOTE: The lines in RED should be made into a single line when typed in. Make sure these is a space between part1 and /media.
An alternate first line for the above script, you may wish to try if you have users logging in from other terminals, and this causes a problem. This will exclude them. Most current distros begin allocating desktops at tty1 or tty7:
hisname=`who | awk '/tty[17]/ {print $1;}'`
For PCLinuxOS users, or if tty[17] returns blank, try changing "[17]" to "8". After a reboot, your new udev rule should be available. Plug in your remote and the icon will appear on your desktop. You can unmount it in the normal way.
Set up RemoteMasterIR to point to it correctly from its menus:
Remote > Interface > JPS... > Other : /media/your-user-name/REMOTE/settings.bin
Normally, with any USB-storage type interface, you have to un-mount it before unplugging, else data may get broken. But when Linux is detected as the OS, RMIR does not use a standard copy command, instead writes directly over the existing file, and is not cached. This means that it is safe to unplug once the data is transmitted. One distro tested requires root password, and RMIR to be closed, to un-mount. This author unplugged the remote several times after uploads to the remote had completed, and had no issues whatsoever.
