Djoss

For this amount of data, I don't know an alternative that would be the same price or cheaper. Also, I would take the completion time estimate with a grain of salt. The deduplication process can influence a lot the time to complete the backup (i.e. it can take much less time than indicated).

Can you try with image version 1.18.1 to see if you have the same issue ?

Did you check if the latest version of the container has the same behaviour ?

I'm not sure to understand how you mapped folders from the host to the container. Can you share your container settings ?

You can probably use the AUTOMATED_CONVERSION_INSTALL_PKGS environment variable to install it and use it in your hooks ? https://github.com/jlesage/docker-handbrake#environment-variables

Can you try to enabled privileged mode to see if it works ?

Which speed are you expecting ? Do you see the same thing with different sources ?

You can look at /mnt/user/appdata/HandBrake/log/hb/conversion.log for details about the conversions.

When you edit the container settings, there is a toggle at the upper-right corner that allows you to switch to the Advanced View. Once in that view, you will be able to click the Edit button of the "Storage" setting. In this new window, you can change the "Access Mode" to "Read/Write".

No, these logs are not related to CrashPlan, but to the VNC connection for the UI. In CrashPlan, you can look at Tools->History. You should see the "effective rate". The should give you an indication of how effective is the deduplication.

I'm not aware of any other workaround... But note that while the upload speed is lower, the amount of data to upload should also be much lower.

Yes, CrashPlan removed this file. They always said its modification was not supported.... but they have taken a step further in recent versions.

Ok, the problem is caused by ".plex-sync". When checking for changes in the folder, the whole folder is ignored because of this hidden folder. As a quick fix, renaming ".plex-sync" to "plex-sync" should work.

There is no more log in this area... To get a complet picture of the container environment, maybe you can share the output of "docker inspect FileBot"?

I assume the input folder is /external-drive/.plex-sync/media/movies/ ? Changes to the hidden folder .inProgress won't trigger the AMC script. However, once the file is moved to /external-drive/.plex-sync/media/movies/, the AMC script should be triggered within a minute.

Are you doing any change to the input folder? The AMC script won't be invoked if no change is detected in the output folder.

By default, the mapping of /storage is read-only. If you want to restore to /storage, you need to edit the container settings and change /storage to be read/write (you need to enable advanced view to do this).

Did you look at the container's log to see what is happening ?

Ok, let me know if the issue persists after that.

Is it still doing that ? Do you have more details in Tools->History ?

Can you look at /mnt/user/appdata/CrashPlanPRO/log/service.log.0 to see if there is anything interesting (errors)?

This is a common behaviour. You can google for it for more details, but basically Handbrake/encoders are not necessarily good at using all the cores, especially above a certain number.

Are you using the default window size (1280x768) ?

With the latest version of unRAID, this should not be required anymore. Else, to the Extra Parameter field, you can add this: --security-opt seccomp=unconfined

Can you try the latest version of the Docker image to see if this problem is fixed?