 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Jellby
Joined: 24 May 2018
Posts: 16
|
 Posted: Thu May 24, 2018 2:14 pm Post subject: URC-6440 on Linux and code programming |
 |
|
I just bought a URC-6440 remote, hoping that I can program it on Linux to control a couple of devices for which the remote controller is really not reliable.
When I plug the remote, I can mount the drive, read the the "settings.bin" file, and even write it with (with dd, as suggested here).
I run RM (java -jar RemoteMaster.jar) and it seems to work fine, but when I try to "download from remote" I get an error: "Command lsblk exited with an error code 1" and then "No remote found". Just running "lsblk" from a command line seems to work fine:
| Code: | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 923,3G 0 part /
└─sda3 8:3 0 7,7G 0 part [SWAP]
sdb 8:16 0 232,5K 0 disk
└─sdb1 8:17 0 232K 0 part /media/username/OFA REMOTE |
I added my user to the "dialout" group, although there's no tty device created when I plug the remote. Should the remote be mounted or unmounted to work with RM (I get the same behaviour, anyway).
Well, since I can read the settings.bin from the remote, I can open the file in RM, and it seems to work (except that when I try to save the file, modified or not, as a .bin, I get "writeRemote returned -1"). But now I encounter the problem of programming the remote for the right devices, which are as follows:
First, NAD D 3020 amplifier. The default NAD codes in the remote don't seem to work (I got as far as turning the device off, but nothing else). However NAD has released a document with the codes, which looks like:
| Code: | Function Format Address Data Address Data
Hex Hex Dec Dec
Aux 1 NEC 877C 9B 34684 155
Aux 2 NEC 877C C0 34684 192
Bluetooth NEC 877C C2 34684 194
Coax 1 NEC 877C 85 34684 133
Computer NEC 877C 91 34684 145
Mute NEC 877C 94 34684 148
Optical 1 NEC 877C 89 34684 137
Optical 2 NEC 877C 8D 34684 141
Power Off NEC 877C C8 34684 200
Power On NEC 877C 25 34684 37
Source Down NEC 877C 1D 34684 29
Source Up NEC 877C 1A 34684 26
Volume Down NEC 877C 8C 34684 140
Volume Up NEC 877C 88 34684 136 |
Please tell me this information can be used to generate a device upgrade (and how), or point me to the appropriate upgrade. The original remote is as good as broken, so using it for learning codes is almost hopeless.
The second one is an unbranded DVD remote I found around left by the previous occupants of the apartment. I used it to "teach" a Raspberry Pi, and generate a lirc config file that looks like this:
begin remote
| Code: | name lircd.conf
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100
gap 107928
begin raw_codes
name 1
9038 4450 604 528 603 532
577 554 578 529 600 1666
605 528 581 526 583 550
581 1659 580 553 578 1662
577 1663 598 535 574 1666
606 1660 601 1639 579 554
576 530 601 1666 605 1635
584 1656 605 528 581 1659
602 530 579 1661 600 1667
604 502 607 526 584 550
580 1659 602 531 578 1663
608
... |
Can I use this somehow to directly program the URC-6440, or find out which device this unknown remote matches? I'd rather not have go through the learning procedure.
I'd appreciate any help and advice. |
|
| Back to top |
|
 |
yaworski
Joined: 22 Jun 2014
Posts: 450
Location: Warsaw, Poland
|
| Posted: Thu May 24, 2018 2:51 pm Post subject: |
|
|
Which Linux distribution and version are you using?
Regarding the lsblk command, try running
| Code: | | lsblk -npro label,fstype,mountpoint |
This is exactly how RMIR calls it. Maybe you have different version of that command which doesn't support all arguments.
Can you show the output of following command?
| Code: | | ls -l `which lsblk` |
Regarding the lirc raw signal data, you first need to decode it and extract information like device and function. You can do that using IrScrutinizer. I've just copied the part below "name 1" (only numerical values) and pasted it directly into IrScrutinizer (there's a button Paste & Src.) and I've got information that this is a NEC, device = 16, subdevice = 237, obc = 92.
_________________
Marcin |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Thu May 24, 2018 3:21 pm Post subject: |
|
|
| yaworski wrote: | | Which Linux distribution and version are you using? |
Kubuntu 14.04
(Quite outdated, I know... I have to update, but need some spare time for that. An upgrade to 16.04 gone wrong in another computer made me stick with this version here.)
| Quote: | Regarding the lsblk command, try running
| Code: | | lsblk -npro label,fstype,mountpoint |
This is exactly how RMIR calls it. Maybe you have different version of that command which doesn't support all arguments. |
Indeed, it says -p is not a valid option. Maybe I can devise an alternate script/program that does the job and alias it... How is the output supposed to look like?
| Quote: | Can you show the output of following command?
| Code: | | ls -l `which lsblk` |
|
Sure, here it is:
| Code: | | -rwxr-xr-x 1 root root 44688 nov 23 2016 /bin/lsblk |
| Quote: | | Regarding the lirc raw signal data, you first need to decode it and extract information like device and function. You can do that using IrScrutinizer. |
Thanks, that will be most useful, I'll experiment there.
Any idea for the "writeRemote returned -1" when trying to save to disk (not to the remote)? I'm afraid if I can't save the changes I do with RM, I won't get quite far... |
|
| Back to top |
|
|
yaworski
Joined: 22 Jun 2014
Posts: 450
Location: Warsaw, Poland
|
| Posted: Fri May 25, 2018 3:06 am Post subject: |
|
|
It seems that the -p flag for lsblk is not needed anyway so I've removed it from RMIR.
I've prepared a test build with this change:
https://www.dropbox.com/s/bc7tfj5l58foard/RemoteMaster.jar?dl=1
Just replace the RemoteMaster.jar file with the one from the link above. Make a copy of the original one just in case.
Regarding working with URC-6440, please remember that the remote's settings.bin file only stores what is required by the remote. So if you start making more advanced configurations, name functions in your device upgrades etc and upload it to the remote, all these names and descriptions and any unused functions will be lost when you download back from the remote.
The best way to work with URC-6440 is to always save your work to the rmir file, which keeps everything, and don't do any changes directly on the remote. To change something on the remote, don't download from the remote but open the rmir file, do some changes and upload to the remote (it'll overwrite any changes you've done on the remote).
_________________
Marcin |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Fri May 25, 2018 12:03 pm Post subject: |
|
|
Thanks, with I don't get the lsblk error anymore, but still get no remote detected.
As for saving the files, thank you for the warning, I was actually starting to get confused. In any case, since the remote is not detected, I can't save to the remote directly, I have to do it externally with dd, so I need to save a .bin file from RM. I've found out that saving to a new file returns the -1 error, but I can overwrite an existing file, so it seems I've found a way to upgrade the remote.
I've also discovered that one of the NAD codes has most of the keys I needed, and could establish the relation between the hex codes provided by NAD and the codes in RM, so I was able to add the missing keys and configure a fully working device upgrade and I'm a happy man now. If I would like to upload the upgrade here, which setup code should I use? Should I replace the most similar existing one or find some empty slot? Or it doesn't matter? |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Fri May 25, 2018 12:26 pm Post subject: |
|
|
| Jellby wrote: | | Thanks, with I don't get the lsblk error anymore, but still get no remote detected. |
I could try in a Kubuntu 16.04 box, and everything works fine there. Sorry for the noise. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 19462
Location: Chicago, IL
|
|
| Back to top |
|
|
yaworski
Joined: 22 Jun 2014
Posts: 450
Location: Warsaw, Poland
|
| Posted: Tue May 29, 2018 1:25 am Post subject: |
|
|
The -1 error may no be very descriptive but the issue is that RMIR can't produce settings.bin file itself. It needs an already existing file. It's because settings.bin file is not just the remote configuration but also a large part of its firmware (so copying settings.bin to the remote can also be used to upgrade it's firmware or install an extender). So RMIR needs to first read the file, modify just the configuration area and save it back.
Regarding the lsblk issue, can you connect your remote and run
| Code: | | lsblk -nro label,fstype,mountpoint |
on the Kubuntu 14.04 and paste the output here? Maybe the output has a different structure.
_________________
Marcin |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Tue May 29, 2018 11:24 am Post subject: |
|
|
I found out that I could use "Save As" overwriting an existing .bin file, but not creating a new one. Also, the option to "Save As" .bin is only available if I start by opening a .bin file, but not if I open a .rmir file.
Moreover, I could manually set the JPS interface to the settings.bin file on the remote's USB drive. The only problem is that RM seems to somehow keep a hold on the file, so I can't unmount the drive while RM is open.
| Quote: | can you connect your remote and run
| Code: | | lsblk -nro label,fstype,mountpoint |
on the Kubuntu 14.04 and paste the output here? |
Here you go:
| Code: | $ lsblk -nro label,fstype,mountpoint
/boot/efi
/
[SWAP]
/media/username/OFA REMOTE |
Or, if I run it as root:
| Code: | $ sudo lsblk -nro label,fstype,mountpoint
vfat /boot/efi
ext4 /
swap [SWAP]
OFA REMOTE vfat /media/username/OFA REMOTE |
(sic for the linebreaks and spacing) |
|
| Back to top |
|
|
yaworski
Joined: 22 Jun 2014
Posts: 450
Location: Warsaw, Poland
|
| Posted: Tue May 29, 2018 11:56 am Post subject: |
|
|
Ah, I see the problem. RMIR expects following line in the output:
| Code: | OFA\x20REMOTE vfat /path/to/mountpoint/OFA\x20REMOTE/
|
Space is used as a column separator (there are three columns: label, fstype and mountpoint - they are given as a list to the -o option).
Spaces in values in each column should be encoded as \x20, so the parser doesn't split the columns in wrong places. It's exactly what happens in your case.
The second problem is with the missing volume label when you run the command as a normal user. This is really strange. I don't know if this is an issue with the old version of the command or rather with your OS permissions. RMIR expects the label to be there and uses it recognise the remote.
Can you try running:
| Code: | | lsblk -Jo label,fstype,mountpoint |
This should switch output to JSON. If it is supported in your version of lsblk then switching to JSON would help with the first issue. I'm not sure how to deal with second one.
_________________
Marcin |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Tue May 29, 2018 12:06 pm Post subject: |
|
|
| The -J option is not available in this version. |
|
| Back to top |
|
|
yaworski
Joined: 22 Jun 2014
Posts: 450
Location: Warsaw, Poland
|
| Posted: Tue May 29, 2018 12:31 pm Post subject: |
|
|
That's a bummer. So it seems that support for Ubuntu 14.04 won't be possible. Looking for a different solutions is going to be hard - I would need to install that version and try to find out how to deal with the issues. This takes time.
Given that this is 4 years old system version I'm afraid I don't have enough motivation to do that. Sorry. Maybe someone else will jump in and send some patches.
_________________
Marcin |
|
| Back to top |
|
|
Jellby
Joined: 24 May 2018
Posts: 16
|
| Posted: Tue May 29, 2018 12:58 pm Post subject: |
|
|
| yaworski wrote: | | Looking for a different solutions is going to be hard - I would need to install that version and try to find out how to deal with the issues. |
How about just checking all mounted systems for a "settings.bin" file? Of course, that would work for this remote, maybe not for others. If that's not a good solution, I'm fine with leaving 14.04 as unsupported, at least we know why and there is a workaround, and I'll upgrade eventually. |
|
| Back to top |
|
|
davecs
Joined: 28 Mar 2005
Posts: 82
|
| Posted: Fri May 17, 2019 6:26 am Post subject: |
|
|
Sorry to bring an old thread back, but this is the only reference I can find, anywhere on the net, and I wonder whether anyone can help.
I hadn't connected my 6440 remote to my computer for a long time, maybe a year, but I wanted to try to make a couple of things a bit more user friendly, but it just won't connect to my computer in Linux any more. All the previous work I did on it is in Linux. I have two different distros on different partitions, PCLinuxOS-Xfce-edition and MXLinux. I have Windows-7 on another partition, and it connects on there.
This is the output from dmesg -c when I plug it in.
| Code: |
[ 987.884896] usb 1-4.1: new full-speed USB device number 10 using xhci_hcd
[ 987.987035] usb 1-4.1: New USB device found, idVendor=06e7, idProduct=8015, bcdDevice= 0.01
[ 987.987036] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 987.987037] usb 1-4.1: Product: UEI Mass Storage
[ 987.987038] usb 1-4.1: Manufacturer: UEI Remotes
[ 987.987038] usb 1-4.1: SerialNumber: 000000000001
[ 987.992903] usb-storage 1-4.1:1.0: USB Mass Storage device detected
[ 987.993018] scsi host6: usb-storage 1-4.1:1.0
[ 988.998208] scsi 6:0:0:0: Direct-Access PQ: 0 ANSI: 0
[ 988.998511] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 989.000183] sd 6:0:0:0: [sdc] 465 512-byte logical blocks: (238 kB/233 KiB)
[ 989.001028] sd 6:0:0:0: [sdc] Write Protect is off
[ 989.001031] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 989.001922] sd 6:0:0:0: [sdc] No Caching mode page found
[ 989.001923] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 989.123293] sdc: sdc1
[ 989.123296] sdc: p1 size 465 extends beyond EOD, enabling native capacity
[ 989.245896] sdc: sdc1
[ 989.245899] sdc: p1 size 465 extends beyond EOD, truncated
[ 989.250976] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 991.193291] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 991.193293] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 991.193294] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 991.193295] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 991.193296] print_req_error: I/O error, dev sdc, sector 257 flags 80700
[ 991.223496] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 991.223498] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 991.223499] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 991.223500] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 991.223501] print_req_error: I/O error, dev sdc, sector 257 flags 0
[ 991.223503] Buffer I/O error on dev sdc1, logical block 32, async page read
[ 992.270082] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 992.270085] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 992.270086] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 992.270088] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 992.270089] print_req_error: I/O error, dev sdc, sector 257 flags 80700
[ 992.300273] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 992.300275] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 992.300276] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 992.300277] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 992.300278] print_req_error: I/O error, dev sdc, sector 257 flags 0
[ 992.300279] Buffer I/O error on dev sdc1, logical block 32, async page read
|
I wonder if I need to modprobe something or other?
_________________
OFA 7562, OFA 8910, OFA7980, OFA6440 and OARUSB04G. |
|
| Back to top |
|
|
davecs
Joined: 28 Mar 2005
Posts: 82
|
| Posted: Fri Sep 13, 2019 9:00 pm Post subject: Any Linux experts? URC-6440 and OARUSB04G no longer detected |
|
|
If you're a Linux User, and you've ever gone into a root terminal, and, after plugging in one of the remotes URC-6440 or OARUSB04G, looked at the output from the command dmesg, you'll see a few errors. But, with, for example, MX-Linux up to 18.3, the remotes mount and work in RemoteMaster RMIR. This is a sample output:
| Code: |
[ 1800.806348] usb 1-4.1: new full-speed USB device number 13 using xhci_hcd
[ 1801.196420] usb 1-4.1: device descriptor read/64, error -32
[ 1801.398963] usb 1-4.1: New USB device found, idVendor=06e7, idProduct=8015
[ 1801.398968] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1801.398973] usb 1-4.1: Product: UEI Mass Storage
[ 1801.398976] usb 1-4.1: Manufacturer: UEI Remotes
[ 1801.398980] usb 1-4.1: SerialNumber: 000000000001
[ 1801.400071] usb-storage 1-4.1:1.0: USB Mass Storage device detected
[ 1801.400275] scsi host7: usb-storage 1-4.1:1.0
[ 1802.411356] scsi 7:0:0:0: Direct-Access PQ: 0 ANSI: 0
[ 1802.412142] sd 7:0:0:0: Attached scsi generic sg2 type 0
[ 1802.413800] sd 7:0:0:0: [sdd] 465 512-byte logical blocks: (238 kB/233 KiB)
[ 1802.414749] sd 7:0:0:0: [sdd] Write Protect is off
[ 1802.414758] sd 7:0:0:0: [sdd] Mode Sense: 03 00 00 00
[ 1802.415638] sd 7:0:0:0: [sdd] No Caching mode page found
[ 1802.415651] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[ 1802.543184] sdd: sdd1
[ 1802.543195] sdd: p1 size 465 extends beyond EOD, enabling native capacity
[ 1802.670551] sdd: sdd1
[ 1802.670557] sdd: p1 size 465 extends beyond EOD, truncated
[ 1802.675211] sd 7:0:0:0: [sdd] Attached SCSI disk
[ 1806.417792] FAT-fs (sdd1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[ 1806.661943] sd 7:0:0:0: [sdd] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1806.661950] sd 7:0:0:0: [sdd] tag#0 Sense Key : Illegal Request [current]
[ 1806.661955] sd 7:0:0:0: [sdd] tag#0 Add. Sense: No additional sense information
[ 1806.661961] sd 7:0:0:0: [sdd] tag#0 CDB: Write(10) 2a 00 00 00 00 01 00 00 01 00
[ 1806.661965] blk_update_request: I/O error, dev sdd, sector 1
[ 1806.661974] Buffer I/O error on dev sdd1, logical block 0, lost sync page write
|
However, with my favoured distro, PCLinuxOS, which has a more up-to-date system, these remotes stopped mounting a long time ago. This is the corresponding output when mounting fails. As you can see, small differences...
| Code: |
[ 987.884896] usb 1-4.1: new full-speed USB device number 10 using xhci_hcd
[ 987.987035] usb 1-4.1: New USB device found, idVendor=06e7, idProduct=8015, bcdDevice= 0.01
[ 987.987036] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 987.987037] usb 1-4.1: Product: UEI Mass Storage
[ 987.987038] usb 1-4.1: Manufacturer: UEI Remotes
[ 987.987038] usb 1-4.1: SerialNumber: 000000000001
[ 987.992903] usb-storage 1-4.1:1.0: USB Mass Storage device detected
[ 987.993018] scsi host6: usb-storage 1-4.1:1.0
[ 988.998208] scsi 6:0:0:0: Direct-Access PQ: 0 ANSI: 0
[ 988.998511] sd 6:0:0:0: Attached scsi generic sg3 type 0
[ 989.000183] sd 6:0:0:0: [sdc] 465 512-byte logical blocks: (238 kB/233 KiB)
[ 989.001028] sd 6:0:0:0: [sdc] Write Protect is off
[ 989.001031] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 989.001922] sd 6:0:0:0: [sdc] No Caching mode page found
[ 989.001923] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 989.123293] sdc: sdc1
[ 989.123296] sdc: p1 size 465 extends beyond EOD, enabling native capacity
[ 989.245896] sdc: sdc1
[ 989.245899] sdc: p1 size 465 extends beyond EOD, truncated
[ 989.250976] sd 6:0:0:0: [sdc] Attached SCSI disk
[ 991.193291] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 991.193293] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 991.193294] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 991.193295] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 991.193296] print_req_error: I/O error, dev sdc, sector 257 flags 80700
[ 991.223496] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 991.223498] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 991.223499] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 991.223500] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 991.223501] print_req_error: I/O error, dev sdc, sector 257 flags 0
[ 991.223503] Buffer I/O error on dev sdc1, logical block 32, async page read
[ 992.270082] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 992.270085] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 992.270086] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 992.270088] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 992.270089] print_req_error: I/O error, dev sdc, sector 257 flags 80700
[ 992.300273] sd 6:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 992.300275] sd 6:0:0:0: [sdc] tag#0 Sense Key : Illegal Request [current]
[ 992.300276] sd 6:0:0:0: [sdc] tag#0 Add. Sense: No additional sense information
[ 992.300277] sd 6:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 00 01 01 00 00 08 00
[ 992.300278] print_req_error: I/O error, dev sdc, sector 257 flags 0
[ 992.300279] Buffer I/O error on dev sdc1, logical block 32, async page read
|
Now the coming version of MX-Linux 19, based on the latest Stable Debian, is in Beta and I am testing it, the same thing happens there and the remotes do not mount.
The above outputs are for the URC-6440, with the OARUSB04G, the Product Number is 8020, and other differences are superficial.
They can be forced to mount, by a direct command in a terminal, but then there is only root access, RMIR doesn't detect the remote (even as root), and upgrading by copying an updated settings.bin doesn't work (it appears to be updated but it's not!).
Solutions:
1. Boot into Windows 7: Works, but I'd rather not if I can help it.
2. Keep an outdated Linux in a partition on my computer
3. Prepare a bootable drive of an outdated Linux which will do the job.
or...
4. There must be a way to set some sort of udev rule just for these remotes,
which enables them to bypass this security check and just work normally.
I'm prepared to resort to solutions 1-3 if I have to, but I'd rather get it working on my current system.
So my question is, are there any Linux experts here who know how to resolve this?
_________________
OFA 7562, OFA 8910, OFA7980, OFA6440 and OARUSB04G. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
