whipper-team / whipper

Python CD-DA ripper preferring accuracy over speed

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

whipper not finding the drive (whipper docker install)

dabac76 opened this issue · comments

My system (Manjaro 20, 64bit) :

sudo lshw -C disk
*-cdrom
description: DVD-RAM writer
product: CDDVDW SH-224BB
vendor: TSSTcorp
physical id: 0
bus info: scsi@2:0.0.0
logical name: /dev/cdrom
logical name: /dev/sr0
version: SB00
capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
configuration: ansiversion=5 status=ready
*-medium
physical id: 0
logical name: /dev/cdrom

I have installed whipper with : docker pull whipperteam/whipper and I am using the recommended alias with --device /dev/cdrom

whipper drive list

CRITICAL:whipper.command.drive:no drives found. Create /dev/cdrom if you have a CD drive, or install pycdio for better detection

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

Could it be a group issue?

cdrom group inside the container has GID=24. Manjaro defines group named optical with access rights to /dev/sr0 and /dev/sg0 with GID=990. Since these don't match, container is not able to use the optical device.

Quick and unsafe workaround would be the following change to docker run :
docker run -ti --rm --privileged -v /dev/cdrom:/dev/cdrom ... (where on host side /dev/cdrom is a symlink owned by root to /dev/sr0)

More subtle solution that avoids the --privileged flag would be to change the Dockerfile so that it picks the right GID for optical device on the host side and adds worker to this group. For example, a quick hard-coded change in my case was:

# add user
RUN groupadd -f -g 990 optical \
    && useradd -m -u 1000 worker -G optical,cdrom \
    ...

And then run container with:

docker run -ti --device /dev/sr0 ...

@dabac76 Hopefully this issue should now be solved with commit 8676e25 (untested).