Djoss

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".

No problem, great that you found the issue. So now it should work as expected (and exactly like the "java mx" command)

Can you do a dummy change to the config (e.g. toggle privileged mode on and off) and apply ? Then take note of the command that is executed to create the container.

Even though if you specified 4096M in container config ?

How do you look at memory consumption of the container ? Via the "docker stats" command ? I don't know when exactly CrashPlan needs most of the memory, if it's during the synchronization process and/or during the backup process. So you may have to let it run for a while before seeing its "real" memory usage.

Not sure about the inconsistency. Is the variable defined only once ? Maybe try to re-apply the setting. But the variable seems have been applied properly: [cont-init.d] crashplan-pro.sh: setting CrashPlan Engine maximum memory to 3072M You can confirm by looking at /mnt/user/appdata/CrashPlanPRO/log/engine_output.log: You should have a line with "-Xmx3072m" (or -Xmx4096m if you changed it via CP without restarting).

Looks good... Just to make sure, provide the whole log: docker logs CrashPlanPRO

Looks like the variable is not set correctly. Can you provide the output of the following command: docker inspect CrashPlanPRO

If you look at the container's log, do you see a message like this: setting CrashPlan Engine maximum memory to 4096M

It seems that custom encryption key is no longer supported: https://www.reddit.com/r/Crashplan/comments/ki4b70/crashplan_no_longer_supports_custom_key_encryption/ However, note that your data its still encrypted, you just don't have control on the encryption key.

So you get the same speed no matter the DVD disc ? Do you have a CC (Closed Caption) track selected ?

Ok, so this confirms that MakeMKV still have issue with the Java version used vs the different types of protections.

The Pro version cannot be downloaded without paying for it first. So I think the software is not using a licensing mechanism, which mean that it would be impossible to legally have a Docker version of it.