Hi there,

I'm posting in the hopes there is a way to properly reset, or reinitialize usb to sata optical devices that typically map to `/dev/sr*` without a restart of unraid.

If you have used ARM or Ripper, and have a usb based optical drive you have likely come across posts like this (https://github.com/jlesage/docker-makemkv/issues/82#issuecomment-956159077) that describe a bad state, where your optical disk is mounted and accessible on the unraid host:

*@*:~# lsscsi
...
[1:0:0:0]    cd/dvd  HL-DT-ST BD-RE  WH14NS40  1.05  /dev/sr0 
...

Reporting properly, but when passed into a container, the drive cannot detect a disk.
Ripper:

10.12.2024 19:26:38 : No disc inserted, checking again in 1 minute.

ARM results in whats described in this thread: https://github.com/automatic-ripping-machine/automatic-ripping-machine/issues/1060

Running arms main ripper script returns a seemingly functional disk:

*@*:/home/arm# python3 /opt/arm/arm/ripper/main.py -d sr0
[2024-12-11 01:36:34,967] INFO ARM: __init__.<module> Setting log level to: INFO
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: CURRENT_TAGS: :uaccess:systemd:seat:
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: DEVLINKS: /dev/disk/by-id/usb-HL-DT-ST_BD-RE_WH14NS40_0000000001CD-0:0 /dev/cdrom /dev/disk/by-path/pci-0000:49:00.0-usb-0:7.2:1.0-scsi-0:0:0:0
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: DEVNAME: /dev/sr0
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: DEVPATH: /devices/pci0000:40/0000:40:03.6/0000:46:00.0/0000:47:0c.0/0000:49:00.0/usb7/7-7/7-7.2/7-7.2:1.0/host1/target1:0:0/1:0:0:0/block/sr0
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: DEVTYPE: disk
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: DISKSEQ: 121
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_BUS: usb
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_CDROM: 1
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_BD: 1
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_BD_R: 1
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_BD_RE: 1
[2024-12-11 01:36:35,216] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_BD_R_RRM: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_BD_R_SRM: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_CD: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_CD_R: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_CD_RW: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_PLUS_R: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_PLUS_RW: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_PLUS_R_DL: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_R: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_RAM: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_RW: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_RW_RO: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_RW_SEQ: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_R_DL: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_R_DL_JR: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_DVD_R_DL_SEQ: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_MRW: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_MRW_W: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_CDROM_RW_REMOVABLE: 1
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_FOR_SEAT: block-pci-0000_49_00_0-usb-0_7_2_1_0-scsi-0_0_0_0
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_INSTANCE: 0:0
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_MODEL: BD-RE_WH14NS40
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_MODEL_ENC: BD-RE\x20\x20WH14NS40\x20
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_MODEL_ID: 55aa
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_PATH: pci-0000:49:00.0-usb-0:7.2:1.0-scsi-0:0:0:0
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_PATH_TAG: pci-0000_49_00_0-usb-0_7_2_1_0-scsi-0_0_0_0
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_REVISION: 1.05
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_SERIAL: HL-DT-ST_BD-RE_WH14NS40_0000000001CD-0:0
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_SERIAL_SHORT: 0000000001CD
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_TYPE: cd
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_USB_DRIVER: usb-storage
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_USB_INTERFACES: :080650:
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_USB_INTERFACE_NUM: 00
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_VENDOR: HL-DT-ST
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_VENDOR_ENC: HL-DT-ST
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: ID_VENDOR_ID: 174c
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: MAJOR: 11
[2024-12-11 01:36:35,217] DEBUG ARM: job.parse_udev pyudev: MINOR: 0
[2024-12-11 01:36:35,218] DEBUG ARM: job.parse_udev pyudev: SUBSYSTEM: block
[2024-12-11 01:36:35,218] DEBUG ARM: job.parse_udev pyudev: SYSTEMD_MOUNT_DEVICE_BOUND: 1
[2024-12-11 01:36:35,218] DEBUG ARM: job.parse_udev pyudev: TAGS: :uaccess:systemd:seat:
[2024-12-11 01:36:35,218] DEBUG ARM: job.parse_udev pyudev: USEC_INITIALIZED: 1566889546703
[2024-12-11 01:36:35,218] INFO ARM: main.<module> ARM is trying to write a job to the empty.log, or NAS**.log

But ARM can't find a disk it seems. Opening/closing the tray results in the "Not CD, Blu-ray, DVD or Data. Bailing out on sr*" error linked above.

I'm asking about this, because I have 4 disks to rebuild and I'm just over 50% through the first one (See screenshot), it's a huge pain to restart the whole sever when the optical disk decides to stop working. If anyone has any ideas how to reinitialize the disk it would be a big help.

Things I have tried and others online have tried:

• Restart the docker containers - No impact/the issue is on the host (Or in a dependency like makemkv/outside the scope of the ripping tools)
• Disconnect, and reconnect the usb drive

Edited December 11, 20241 yr by paperblankets
Improved logs

unplug the usb and replug

there also exist a /dev prod command to echo something and rescan.

lack of info...

 

/sys/bus/usb/drivers/usb-storage/

it might be under another directory like usb or uhci_hcd, ehci_hcd, xhci_hcd, etc., depending on your USB controller.

 

Unbind the Device:

echo '1-2' | sudo tee /sys/bus/usb/drivers/usb-storage/unbind
 

Rebind the Device:

echo '1-2' | sudo tee /sys/bus/usb/drivers/usb-storage/bind
 

so:
 

lsusb
ls /sys/bus/usb/devices/

Navigate to the driver binding interface (assuming usb-storage for SATA optical devices):
cd /sys/bus/usb/drivers/usb-storage/

 

#unbind:
echo '1-2' | sudo tee unbind
#rebind:
echo '1-2' | sudo tee bind

 

You may not be passing the disk drive properly to the docker... exmpale makmkv:



To pass a single usb attached disk drvie.

more data on that here:

 

That solution unfortunately is not working.
I used `lsusb` to identify the bus and device.
Checked `/sys/bus/usb/devices/` and grabbed the hub 'id' (7-7.2:1.0).
ran `echo '7-7.2:1.0' | sudo tee unbind`
ran `echo '7-7.2:1.0' | sudo tee bind`

Started arm container, `/dev/sr0` device is identified just as it was before, if I put a disk in the tray and close it the following error occurs:

Dec 11 18:06:20 3ef4700793ce ARM: [ARM] Entering docker wrapper
Dec 11 18:06:20 3ef4700793ce ARM: [ARM] Not CD, Blu-ray, DVD or Data. Bailing out on sr0

For whatever reason a full restart of unraid is going to resolve this issue. The rebuild is only 80% done though so I have time to try some other things if anyone has any ideas.

 

Quote

You may not be passing the disk drive properly to the docker... exmpale makmkv:

It's being passed as a device/properly (but only sr0, no other devices).
I can reproduce this in unraid managed containers, or just in compose (If I come across more examples of discussions of this (a restart making the disk drive work again) online I will edit the initial post).

Usually you need /dev/sr0 and /dev/sg1
this sounds like the loppback on how linux handles dvd/blueray burner is usd at first read in /dev/sg0 and after it loop backs to the next /dev/sg1 etc...

It why I shared the 

ls /dev/{cdrom,sr*,sg*}

lshw -C disk

you would need to pass more for that device its like passing a prt of the disk drive not the entire disk drive...

also the echo command should be a 1 or 2 in the unbind folder and 1 or 2 in the bind folder. the tee comand is to view the value set.

@bmartino1 Well you helped me get to the root(s) of the issue!

#1 I had an expired key for MakeMKV. I resolved that.
#2 The disk I have been testing is not detected on my other players. I should have tested the disk to start with.

It could be the unmount would resolve this (The issue I thought I was having) issue. I will await the next time AMD has an issue with my reader, and test that method again.

 

Quote

Usually you need /dev/sr0 and /dev/sg1

That's good to know, I will make sure both are passed through, I don't believe I have both passed through currently.

Edited December 11, 20241 yr by paperblankets

Hoping I can get some help with the similar issue on this. 

 

I have a USB optical drive, and after a day or 2, the usb optical drive disappears and isn't seen by the system. I try:

lsscsi -g

and it no longer shows me the device any more. I move it to a different 1 of the 3 USB ports on the computer and it shows up as sr0 and sg13. I use it for a few makemkv rips and then I leave it idle for a few days and then it disappears. run the lsscsi -g command and it is gone. At this point I cycle through a new usb port, it works until the same cycle happens. But once I cycle through all 3 ports, no matter what port i stick it in to, it no longer shows up. A full reboot of Unraid will resolve, but nothing keeps the usb optical drive in the list.

 

 

On 4/2/2025 at 11:17 PM, iDashX said:

Hoping I can get some help with the similar issue on this. 

 

I have a USB optical drive, and after a day or 2, the usb optical drive disappears and isn't seen by the system. I try:

lsscsi -g

and it no longer shows me the device any more. I move it to a different 1 of the 3 USB ports on the computer and it shows up as sr0 and sg13. I use it for a few makemkv rips and then I leave it idle for a few days and then it disappears. run the lsscsi -g command and it is gone. At this point I cycle through a new usb port, it works until the same cycle happens. But once I cycle through all 3 ports, no matter what port i stick it in to, it no longer shows up. A full reboot of Unraid will resolve, but nothing keeps the usb optical drive in the list.

 

 

...

...

...

 

Please make a post in general support, this is kinda a necro thread... would never have know you pposted...

 

This appears to be more of a misconfiguration on how you are passing the dev sr0 sg0 and additional needed linux device paths for your disk drive. And/or incompatible usb ata with potential disk drive issues...

 

 

 

Review...

 

https://forums.unraid.net/topic/58352-support-djoss-makemkv/page/35/#findComment-1511766