Djoss

Yes, a new key is needed. It should be published soon. Once the new key is published on the MakeMKV forum, you just need to restart the container: the key will be fetched automatically.

Yeah currently simultaneous encodes is not supported, but this is a good suggestion. Could you add you feature request to https://github.com/jlesage/docker-handbrake/issues, so it doesn't get lost ?

QSV support in HandBrake seems flaky and can break for some processor... Can you share the log ? Which CPU are you using ?

You can add an environment variable named "LANGUAGE", with its value being the language you want (e.g. "fr_FR.UTF-8").

I think this is not related to the container itself, but to the Linux version of HandBrake (you would probably be able to reproduce the same behaviour in a Linux VM). Try to look at the MakeMKV forum. For example, I found the following post, which seem to describe your problem. But I'm not sure if the solution applies to unRAID though. https://forum.makemkv.com/forum/viewtopic.php?f=3&t=25357&p=109149&hilit=hang#p109149

Maybe try to set the backup schedule to limit when CrashPlan is allowed to backup files?

Yes, working on this

This was with the UI and not the automatic video converted? As you mentioned, looks like that the file has been removed while Handbrake was handling the file...

Which documentation are you talking about ?

For me, this seems to be a good idea (creating a new library for processed files). The other option you have, if you want to differentiate converted and non-converted files, is to use a custom hook to rename the converted files. https://github.com/jlesage/docker-handbrake#hooks

Is the container staying up and running ? Or it shutdown itself ? Did you look at the container's log for any errors?

What the browser is displaying exactly when connecting to the UI ?

Is the issue you have about a "Local destination" ?

You can look at the file at /mnt/user/appdata/CrashPlanPRO/conf/jvm_args. It should have something like "-Xmx6144m". This same value should also be seen in /mnt/user/appdata/CrashPlanPRO/log/engine_output.log. Yes, this is normal, the cache can get very large. Mine is at 13GB.

Instead of using java mx ,there is a setting in container's configuration that can be used: "Maximum Memory".