JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Linux support for URC6440 and OARUSB04G
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sun Sep 20, 2020 1:05 pm    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

Edit: This thread now explains how to use URC6440 and OARUSB04G on current Linux systems on which the remotes no longer auto-mount. It started as a discussion thread but finished giving the solution.

RMIR is supposed to have support for Simpleset remotes such as URC6440 on Linux. That support was not written by me, I am very new as a Linux user but am currently using Ubuntu 20.04 and testing RMIR on it with a wide range of remotes. The only one I have had trouble with is the URC6440. Here is what I have found.

Simpleset remotes appear to the OS as a filesystem. In Windows, connecting the URC6440 makes it show up as a drive with label OFA REMOTE. For both Windows and Linux, RMIR identifies a Simpleset remote by searching the mounted drives for one with REMOTE in its label. But when I connect the URC6440 to my Linux machine, it does not automatically mount. I can manually mount it (using filetype vfat) and then the lsblk command that RMIR uses to search through mounted filesystems does actually find it, but the only data that it shows for it is the mount point. No filetype, no label. They are blank, so RMIR has no way to identify the remote even though it is mounted. With it mounted, I can manually copy the settings.bin file from the remote, so the mount is functioning, it is that RMIR has no way to find it.

Any help with understanding what is going on, and if possible finding a way round it, would be very welcome. I cannot be the only user affected by this issue and would very much like to fix RMIR to handle it if possible.
_________________
Graham


Last edited by mathdon on Tue Sep 22, 2020 12:52 pm; edited 1 time in total
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Mon Sep 21, 2020 3:21 am    Post subject: Reply with quote

When the 6440 was new, om my then-Fedora system mounted the remote without problems as soon as the remote was plugged in. Modern systems do not. Instead, there are a number of error messages when connecting the remote:
Code:
[ 6671.632563] usb 1-1.3: new full-speed USB device number 12 using xhci_hcd
[ 6671.715609] usb 1-1.3: New USB device found, idVendor=06e7, idProduct=8015, bcdDevice= 0.01
[ 6671.715615] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6671.715618] usb 1-1.3: Product: UEI Mass Storage           
[ 6671.715620] usb 1-1.3: Manufacturer: UEI Remotes             
[ 6671.715623] usb 1-1.3: SerialNumber: 000000000001
[ 6671.721564] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[ 6671.722663] scsi host7: usb-storage 1-1.3:1.0
[ 6672.767261] scsi 7:0:0:0: Direct-Access                                    PQ: 0 ANSI: 0
[ 6672.767877] sd 7:0:0:0: Attached scsi generic sg7 type 0
[ 6672.769621] sd 7:0:0:0: [sdg] 465 512-byte logical blocks: (238 kB/233 KiB)
[ 6672.770584] sd 7:0:0:0: [sdg] Write Protect is off
[ 6672.770588] sd 7:0:0:0: [sdg] Mode Sense: 03 00 00 00
[ 6672.771487] sd 7:0:0:0: [sdg] No Caching mode page found
[ 6672.771490] sd 7:0:0:0: [sdg] Assuming drive cache: write through
[ 6672.905186]  sdg: sdg1
[ 6672.905196] sdg: p1 size 465 extends beyond EOD, enabling native capacity
[ 6673.028186]  sdg: sdg1
[ 6673.028189] sdg: p1 size 465 extends beyond EOD, truncated
[ 6673.047467] sd 7:0:0:0: [sdg] Attached SCSI disk
[ 6674.229042] sd 7:0:0:0: [sdg] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[ 6674.229048] sd 7:0:0:0: [sdg] tag#0 Sense Key : Illegal Request [current]
[ 6674.229052] sd 7:0:0:0: [sdg] tag#0 Add. Sense: No additional sense information
[ 6674.229056] sd 7:0:0:0: [sdg] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 6674.229062] blk_update_request: I/O error, dev sdg, sector 257 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 6674.259328] sd 7:0:0:0: [sdg] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[ 6674.259334] sd 7:0:0:0: [sdg] tag#0 Sense Key : Illegal Request [current]
[ 6674.259337] sd 7:0:0:0: [sdg] tag#0 Add. Sense: No additional sense information
[ 6674.259342] sd 7:0:0:0: [sdg] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 6674.259347] blk_update_request: I/O error, dev sdg, sector 257 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 6674.259353] Buffer I/O error on dev sdg1, logical block 32, async page read


Most likely, the UEI implementation is, with the current Linux driver interpretation, buggy.
Back then, it may be possible that RMIR handled it.
Windows may also be more forgiving.

However, it is still possible to mount it manually, and read and write to settings.bin.

My gut feeling is that we can probably come up with a kludge, possibly by using udev (mounting from udev rule -- but how is unmounting to be handled?). However, such a solution would probably be quite fragile -- there are simply so many variable.

So I suggest just letting RMIR reading and writing to the file settings.bin, located anywhere in the file system, and leave it to the user to transfer it to/from the remote.

Since the remote is not available any more (ebay.com currently only has two used for sale), I do not consider it worth the effort of doing anything more elaborate.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Sep 22, 2020 8:26 am    Post subject: Reply with quote

Barf wrote:
So I suggest just letting RMIR reading and writing to the file settings.bin, located anywhere in the file system, and leave it to the user to transfer it to/from the remote.

The copying back to the remote with Linux is not straightforward, see this post from 2016. Marcin built a version of this into RMIR so that uploading would work transparently, and I really would like to get that working again.

I have found a simple workaround for downloading. Manually mount the remote, then go to Remote > Interface > JPS in RMIR, select "Other" as the port and enter the path to the settings.bin file on the mount point. The remote then downloads in the usual way. But if you try an upload, the line

Code:
FileChannel o = FileChannel.open( Paths.get( filePath ), StandardOpenOption.CREATE, StandardOpenOption.WRITE, StandardOpenOption.SYNC );

which is line 390 in JPS.java, gives an "Access denied" error. I have tried using sudo chmod to change the access permissions on the settings.bin file (only root has write permission) but that fails. The permissions do not change. A web search suggests this is because the filesystem on the remote, which is FAT12, does not support permissions but Linux still seems to use them without permitting them to be changed.

I can get uploading to work, by running RMIR as root using sudo, but that is not a good thing to do. Is there any other way round the permissions problem? I am happy to leave it so the user has to mount the remote manually and set the port as I wrote above, but would really like it to work for uploading as well as downloading.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Sep 22, 2020 8:45 am    Post subject: Reply with quote

Quote:
then go to Remote > Interface > JPS in RMIR, select "Other" as the port and enter the path to the settings.bin file on the mount point.

... and this works also for a file in the local file system, right? Sounds like the fallback I am asking for.

Quote:
... gives an "Access denied" error. I have tried using sudo chmod to change the access permissions on the settings.bin file (only root has write permission) but that fails. The permissions do not change. A web search suggests this is because the filesystem on the remote, which is FAT12, does not support permissions but Linux still seems to use them without permitting them to be changed.

Mount with the mount option umask=0. Moreover, you can add an entry to fstab allowing non-sudo mounts, and the umask=0 added automatically. See man fstab.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Sep 22, 2020 9:21 am    Post subject: Reply with quote

Many thanks. Tried and tested. The umask option works perfectly Very Happy . I've still to look into fstab but the problem is solved with umask.

Barf wrote:
and this works also for a file in the local file system, right?

I'm not sure if you are really asking that question, but the answer is yes. That is what the "Other" port option was created for, as there was no mount issue then, but it works just fine for manual mounting too.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 1402
Location: Munich, Germany

                    
PostPosted: Tue Sep 22, 2020 10:38 am    Post subject: Reply with quote

With the line
Code:
/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /urc6440 vfat   user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

in /etc/fstab you can mount it without root/sudo. Just
Code:
mount /urc6440

The directory in the second position can be any existing directory. Before removing the remote, do
Code:

umount /urc6440

otherwise the system might misbehave.

Tested with Fedora.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Tue Sep 22, 2020 12:47 pm    Post subject: Reply with quote

That works perfectly, too Very Happy . Many thanks again.

The first element of Barf's suggested entry for fstab, given as
Code:
/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1

may vary between different models of Simpleset remotes, so I recommend using your file manager to look at the contents of /dev/disk/by-id to check, and if necessary change that element. I am renaming this thread and making it a Sticky, so that it is available easily to other users in future.
_________________
Graham
Back to top
View user's profile Send private message
HamburgerHelper1



Joined: 22 Feb 2014
Posts: 567

                    
PostPosted: Thu Sep 24, 2020 5:31 am    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

I have not had time to test this yet.
Hopefully i will somtime next week.
From what i see it looks like the instructions on this page
is all i need to make it work for my OARUSB04G
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Fri Sep 25, 2020 12:32 pm    Post subject: Reply with quote

I have the first version of the OARUSB04G, signature 257604 which RMIR identifies as an OARUSB04G 4000, with Extender v1.04 installed and I have tested the above with it. To my surprise nothing at all needs changing. That first element of the fstab entry is exactly the same for the US remote and its European counterpart the URC6440. So you should have no trouble with yours. If you do have any problem, please post here and I will try to sort it out.
_________________
Graham
Back to top
View user's profile Send private message
HamburgerHelper1



Joined: 22 Feb 2014
Posts: 567

                    
PostPosted: Sat Sep 26, 2020 1:30 pm    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

Ok so to make things easier for me to follow i made the /urc6440 folder and added the line to the fstab file
I can mount /urc6440 and i can see the setting .bin file
I set RMIR at jps, other and /urc6440 as the path
unfortunately rmir gives no remote found i also tried just urc6440
I have usbmount program installed that may work for this in the future but for now i have it disabled.
Am i setting path wrong ? any ideas what i am doing wrong ?
This is on xubuntu 20.0 4
Back to top
View user's profile Send private message
HamburgerHelper1



Joined: 22 Feb 2014
Posts: 567

                    
PostPosted: Sat Sep 26, 2020 1:48 pm    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

here is rmaster.err

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26084
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Sep 26, 2020 3:29 pm    Post subject: Reply with quote

The path you enter at JPS "Other" must include the settings.bin, so in your case it should be /urc6440/settings.bin and not just /urc6440. If you can see the settings.bin file in the /urc6440 folder after mounting, that should be the only problem.

Do remember to do umount /urc6440 after you have finished with RMIR.
_________________
Graham
Back to top
View user's profile Send private message
HamburgerHelper1



Joined: 22 Feb 2014
Posts: 567

                    
PostPosted: Sat Sep 26, 2020 5:03 pm    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

well i will have to try again later im lost.
Restarted from scratch and no go
here is my problem make mounting point sudo mkdir /usbremote
add to end of fstab file

/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /usbremote vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

"usbremote" shows up on desktop and if click say error mounting already mounted
but it changes to file system and shows in file manager
but also if i mount it in terminal "mount usbremote" it says error no file or directory and that i think is why even with corect path rmir will not see it so i am doing something wrong or else how xfce desktop handles things but most likely my mistake
Back to top
View user's profile Send private message
HamburgerHelper1



Joined: 22 Feb 2014
Posts: 567

                    
PostPosted: Sat Sep 26, 2020 5:37 pm    Post subject: Linux support for URC6440 and OARUSB04G Reply with quote

I typed my message wrong the command i used is mount /usbremote
and after a few tries and ready to give up i rebooted computer and now it works
thanks
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4515
Location: Cambridge, UK

                    
PostPosted: Sat Sep 26, 2020 5:51 pm    Post subject: Reply with quote

Thanks for letting me know. I was in the middle of writing a reply to suggest doing a restart, if you had not already done so, when your last message appeared. I suspect the change to fstab does not take effect until after a restart. Glad all is now sorted.
_________________
Graham
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control