Djoss

Does you backup have encryption, compression, etc enabled ? You could try to do a test by performing a backup to a non-USB HDD to see if you get the same speed.

For people that reported similar issue, a reboot did fix it. Maybe this is something you can try.

You mean that the MakeMKV does see the drive, but not the inserted disc ?

You are welcome!

In fact there are 2 devices for each drive: one /dev/srX and one /dev/srY. Both usually need to be mapped. You can use the container log to see if you have correctly mapped the drives: [cont-init ] 54-check-optical-drive.sh: looking for usable optical drives... [cont-init ] 54-check-optical-drive.sh: found optical drive [/dev/sr0, /dev/sg3], but it is not usable because: [cont-init ] 54-check-optical-drive.sh: --> the host device /dev/sg3 is not exposed to the container. [cont-init ] 54-check-optical-drive.sh: found optical drive [/dev/sr1, /dev/sg4], group 19. [cont-init ] 54-check-optical-drive.sh: WARNING: for best performance, the host device /dev/sr1 needs to be exposed to the container. So in you case, one container should have: /dev/sr0 /dev/sg3 And the other should have: /dev/sr1 /dev/sg4 The new image is already available

Ok I will fix the following problem: [cont-env ] SUP_GROUP_IDS_INTERNAL: stat: can't stat '/dev/sr1': No such file or directory However, it seems that only /dev/sr0 and /dev/sg4 are exposed to the container. /dev/sr1 and /dev/sg3 are not. Note that the content of the field should not have "&&". It should be: --device=/dev/sg4 --device=/dev/sr0 --device=/dev/sg3 --device=/dev/sr1 Once all the devices are properly exposed, I think your problem should be fixed.

MakeMKV has not been started with the correct groups... Could you provide the output of: docker logs MakeMKV docker inspect MakeMKV

Which Linux device(s) did you expose ? Can you run "ls -l" on them and report here ? For example: ls -l /dev/sr1 Also, run: docker exec MakeMKV ps And note the PID of MakeMKV UI. You should have a line that looks like this: 823 app 0:45 {makemkv} /opt/makemkv/bin makemkv -std In this example, the PID is 823. With this PID, provide the output of (replace 823 with the PID ou got previously): docker exec MakeMKV cat /proc/823/status

Do you get the same result with: docker exec MakeMKV su-exec app /opt/makemkv/bin/makemkvcon -r --cache=1 info disc:9999

Can you try to run the following command to see if drive is detected: docker exec MakeMKV /opt/makemkv/bin/makemkvcon -r --cache=1 info disc:9999

A new image is being built to fix this.

You can get the container log by running "docker logs VideoDuplicateFinder". You can run the command after the crash.

Do you have anything useful in the container log when it crashes ?

I was able to reproduce. This is an issue with the app itself. I created a bug report for this: https://github.com/0x90d/videoduplicatefinder/issues/398

All you are discussing should not be a concern for FileBot or any applications working with /mnt/user/. The issue/behaviour you are raising seems to be related to unRAID internals. For example, you mentioned that moving a file from a cache-enabled share to a cache-disabled shared does not produce the expected result. From FileBot's point of view, the file has been moved from one folder to the other. However, under the hood, unRAID did not place the file to the expected disks.

It should be good now, even without the patch./fix

This is an unRAID bug. See the following thread: You can install a plugin to fix the issue until the next unRAID version.

Yes I've seen it. Hopefully it will be cosmetic changes only.

This is an unRAID bug. See the following thread:

This is usually caused by a browser plugin blocking something needed by the page.

No, there is no impact on the container itself.

I was not sure if a video player would be useful or not, so I integrated a basic one. Note that you can also use left/right arrow keys. The browser is basically running an HTML VNC client that connects to the application running in the container.

Thanks for the info! I was not aware of this issue.

Support for JMkvpropedit docker container Application Name: JMkvpropedit Application Site: https://github.com/BrunoReX/jmkvpropedit Docker Hub: https://hub.docker.com/r/jlesage/jmkvpropedit Github: https://github.com/jlesage/docker-jmkvpropedit Make sure to look at the complete documentation, available on Github ! Post any questions or issues relating to this docker in this thread.

Support for Video Duplicate Finder docker container Application Name: Video Duplicate Finder Application Site: https://github.com/0x90d/videoduplicatefinder Docker Hub: https://hub.docker.com/r/jlesage/video-duplicate-finder Github: https://github.com/jlesage/docker-video-duplicate-finder Make sure to look at the complete documentation, available on Github ! Post any questions or issues relating to this docker in this thread.