More > JRiver Media Center 29 for Linux
Docker Images for MC29
max096:
--- Quote from: cncb on June 16, 2022, 09:37:54 pm ---I got the permissions sorted by using the user id and group from the working container.
But I get these lines in the log:
[cont-init.d] new-intel-setup.sh: Adding group 937 for device /dev/dri/renderD128.
[cont-init.d] new-intel-setup.sh: Device /dev/dri/card0 cannot be added, as it's owned by root.
--- End quote ---
This means /dev/dri/card0 is owned by root:root on your host. Run the following on your host.
--- Code: ---sudo groupadd video
sudo chown :video /dev/dri/card0
--- End code ---
The first command may fail if the group already exists, in which case thats fine just do the chown. The file/device is owned by group video for me and for bob too. Not sure why it isn't for you.
Then restart the container.
--- Quote from: bob ---Your user probably needs to be added to the video and render groups.
--- End quote ---
That should work too, but should not be necessary. If /dev/dri/card0 is owned by any group at all on the host the script will add that group to the list of group ids that the container will use to start jriver as. So it should not be required for the user to belong to those groups on the host.
cncb:
This is what I get. There is not even a render group and I cannot do a groupadd.
--- Code: ---$ ls -l /dev/dri*
total 0
crw------- 1 root root 226, 0 Jun 7 15:03 card0
crw-rw---- 1 root videodriver 226, 128 Jun 7 15:03 renderD128
--- End code ---
--- Code: ---$ sudo groupadd video
sudo: groupadd: command not found
--- End code ---
max096:
--- Quote from: cncb on June 17, 2022, 02:05:56 pm ---This is what I get. There is not even a render group and I cannot do a groupadd.
--- Code: ---$ ls -l /dev/dri*
total 0
crw------- 1 root root 226, 0 Jun 7 15:03 card0
crw-rw---- 1 root videodriver 226, 128 Jun 7 15:03 renderD128
--- End code ---
--- Code: ---$ sudo groupadd video
sudo: groupadd: command not found
--- End code ---
--- End quote ---
Looks like synology has their own utilities to manage groups and such.
https://global.download.synology.com/download/Document/Software/DeveloperGuide/Firmware/DSM/All/enu/Synology_DiskStation_Administration_CLI_Guide.pdf
There is a section 'Managing local groups — synogroup'. Probably synogroup --add video is what you want to add a group? Bit confused by that it also said that the group will get added to a user. Maybe you can do that in the GUI somewhere too.
You can also just do this if you can't figure out how to add another group
--- Code: ---chown :videodriver /dev/dri/card0
--- End code ---
It does not matter what group it is for the container, it just has to belong to some group. Don't touch the group on /dev/dri/renderD128 it might be necessariy to be that group for something else to work.
Although, thinking about it I did not check for duplicate groups... They just happened to be different groups on my system. It might crash on startup if the same group appears twice right now gotta try that.
EDIT: Does not crash, but still gonna prevent it from adding the same group twice anyways.
Here is the revised script. it now no longer should be able to add the same group multiple times.
--- Code: ---#!/usr/bin/with-contenv sh
set -e # Exit immediately if a command exits with a non-zero status.
set -u # Treat unset variables as an error.
log() {
echo "[cont-init.d] $(basename $0): $*"
}
add_device_groups() {
# Add Groups for devices in /dev/dri/
# NOTE: The devices can only be added if they belong to a group that is not the root user on the host.
find /dev/dri/ -type c | while read DRI_DEV
do
DRI_GROUP="$(stat -c "%g" "$DRI_DEV")"
[ "$DRI_GROUP" = "0" ] && { log "Device $DRI_DEV cannot be added, as it's owned by root."; continue; }
if [ -f /var/run/s6/container_environment/SUP_GROUP_IDS ]; then
if cat /var/run/s6/container_environment/SUP_GROUP_IDS | grep -q "\(^\|,\)$DRI_GROUP\($\|,\)"; then
log "Group $DRI_GROUP for device $DRI_DEV already exists. Will not add duplicates."
continue;
fi
echo -n "," >> /var/run/s6/container_environment/SUP_GROUP_IDS
fi
log "Adding group $DRI_GROUP for device $DRI_DEV."
echo -n "$DRI_GROUP" >> /var/run/s6/container_environment/SUP_GROUP_IDS
done
}
[ "$INSTALL_INTEL_GPU_DRIVER" = "0" ] && { log "Intel GPU setup is blocked by INSTALL_INTEL_GPU_DRIVER env variable."; exit 0; }
PROCESSOR_NAME=$(cat /proc/cpuinfo | grep "model name" | head -n 1 | cut -d':' -f2 | awk '{$1=$1};1')
if echo "$PROCESSOR_NAME" | grep -qiw "INTEL" || [ "$INSTALL_INTEL_GPU_DRIVER" = "1" ]; then
log "Setting up Intel GPU driver. Detected processor: $PROCESSOR_NAME"
[ ! -d "/dev/dri" ] && { log "Directory '/dev/dri' not exposed to container. Cannot setup intel gpu."; exit 0; }
[ ! -e "/dev/dri/renderD128" ] && { log "Device '/dev/dri/renderD128' not exposed to container. Cannot setup intel gpu."; exit 0; }
if [ $(dpkg-query -W -f='${Status}' intel-media-va-driver 2>/dev/null | grep -c "ok installed") -eq 0 ]; then
# Install intel driver
log "Installing intel-media-va-driver..."
apt-get update
apt-get install -y intel-media-va-driver
else
log "intel-media-va-driver is already installed."
fi
add_device_groups
fi
--- End code ---
cncb:
Here is what I have now, but my CPU is still being pegged so Hardware Acceleration is not working. Do I have to add some permissions to card0?
--- Code: ---$ ls -l /dev/dri*
total 0
crw------- 1 root videodriver 226, 0 Jun 7 15:03 card0
crw-rw---- 1 root videodriver 226, 128 Jun 7 15:03 renderD128
--- End code ---
max096:
--- Quote from: cncb on June 17, 2022, 03:21:12 pm ---Here is what I have now, but my CPU is still being pegged so Hardware Acceleration is not working. Do I have to add some permissions to card0?
--- Code: ---$ ls -l /dev/dri*
total 0
crw------- 1 root videodriver 226, 0 Jun 7 15:03 card0
crw-rw---- 1 root videodriver 226, 128 Jun 7 15:03 renderD128
--- End code ---
--- End quote ---
card 0 does not have read/write permissions for groups.
--- Code: ---sudo chmod 660 /dev/dri/card0
--- End code ---
The permissions of both files should look the same after running this command.
You also have to enable hardware acceleration in the MC options.
If it still does not work after that, you could try this image: https://hub.docker.com/r/jlesage/handbrake
It's based on the same baseimage and also has quicksync support. Just to cross check wether it's this image or your setup. There is very little setup instructions on dockerhub when you click on the github link youll see more including how to set that up with intel gpus. (Github link: https://github.com/jlesage/docker-handbrake)
I've also tried with NVIDIA, but so far little luck with that. I can run nvidia-smi and it will list the gpu / driver version / cuda version and everything, but it's not used by MC or gpu stresstest programs. Might be that it's my setup and it would actually work. Fedora is not really supported by the nvidia container toolkit. I just used the centos repos.
A good way to test if the GPU can be used is to log into the container and run glxgears
--- Code: ---docker exec -it <container name or id> /bin/bash
apt update
apt install mesa-utils
__GL_SYNC_TO_VBLANK=0 vblank_mode=0 glxgears
--- End code ---
This should utilize your GPU 100% when it's working. You also end up running it as root this way so permissions on those device files don't matter.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version