Djoss

Yes, JRE is already part of the Docker image and I ready to be used by MakeMKV.

Did you check the ownership and permissions of those files ?

You can use a plugin to create a backup of the flash and then include this backup in CloudBerry Backup.

New image available!

Ok thanks, I will fix that.

Themes were not supported officially by the container. How are you changing the theme ?

Did you check if your Docker vDisk is full ? We see some errors in docker.txt related to that.

Great, thanks for the follow-up !

It's under "Devices". The last row has a restore button. And a new Docker image is now available.

Fix is coming today for this. Note that if you have any urgent files to restore, you can also do it from the console at crashplan.com.

You may look at /mnt/user/appdata/CrashPlanPRO/log/backup_files.log.0 to see which files are backup. Also, check @RabidYak answer: maybe the daily verification scan always interrupts the backup of your data.

Yeah I fixed the issue, but looks like I forgot to provide an update here ...

Which connection are you talking about ?

When behind NPM, putty container doesn't handle any certificate. Certificates are handled by NPM. So when using default settings for the putty container (no need to enable sure connection), your proxy host configuration should have Forward IP set to the unRAID IP and the Forward Port set to 7816. You also need to enable "WebSockets Support".

The container port is always 5800. It's the port on the host side that can be changed. I would try to remove duplicated settings. The initial error would have been solved by clearing your browser cache.

BTW, the log still shows which devices should be exposed. If you don't see the output from the UI, try running the command "docker logs MakeMKV".

Please try the latest version, it should be fixed.

This is usually caused by a browser cache issue. Try to clear it, or try to access in an incognito/private window.

Good question. Do you know if this was working with unRAID 6.9.2 ?

The conversion log shows that QSV fails to initialize. This is a known issue that occurs with some CPU models. You may want to use a software encoder, until the problem is fixed.

Correct, only the value is important.

Do you get the same problem when encoding with the same preset using the UI?

In container's settings, you can add a new "Device" and set the value to "/dev/dri/".

Probably a coincidence. The issue was not new, but was visible only when *not* running the latest Docker image.

There is a bug with CrashPlan where it doesn't clean a downloaded update that fails to be applied. However, the latest version of the image includes a change that should prevent that.