Djoss

Does the issue occur while running java ? What are the messages displayed in MakeMKV ?

Where is the destination of your rip ? Is it on your cache drive ?

Which error do you have exactly? "waiting for connection" or "Unable to connect to destination" ?

Did you try to clear the CrashPlan's cache ? https://github.com/jlesage/docker-crashplan-pro#device-status-is-waiting-for-connection

Thanks for reporting, I will update libmediainfo to the latest version.

And when you added this path to the container's setting, did you set it as read/write ?

Is your cache drive full ?

I'm not sure if Filebot offer a such feature. I would look on the Filebot's forum, you will probably find better answers.

What is the location where you are restoring the files?

Yes, I will provide a new image with the new CrashPlan version integrated. Thanks for reporting this. This is currently the most efficient wait for me to know there is a new CrashPlan version available

The FileBot binary is located at /opt/filebot/filebot. It can be used to run your commands.

So you are ripping using the GUI ? I don't think that the issue is related to the fact your are accessing the UI from different locations. Looks like MakeMKV have issue reading the disc. What the MakeMKV's log (in the UI) is saying ?

Did you make sure that JDownloader itself is up-to-date? Help->Find Updates

The main reason was to avoid using privileged ports. This allows nginx to not run as root.

Sorry, I though you were talking about the post conversion hook. So I verified the post watch folder hook, and there is definitively an issue with the param passed to the script. I will fix that.

Arguments passed to the post processing script have always been the same. See https://github.com/jlesage/docker-handbrake#hooks So I'm not sur how your script worked, since the watch folder path is never passed to the script... and the first argument should be the conversion state. Since you are using a single watch folder, you can only set the watch folder like this: WATCH_FOLDER=/watch

The Docker image is based on Alpine 3.12. This is why version 84.0.2 of Firefox is used. I guess I will have to upgrade the image to Alpine 3.13.

The template on unRAID already setup the container with proper values. So if you kept defaults ones, you should be all good!

It would like A. To be more precise, the AMC script would be executed every 30 minutes.

Do you have more details about the failure if you go under History->By Files ? If not, you could have a look at the following log files: /mnt/users/appdata/CloudBerryBackup/logs/log_worker_* Finally, is the failure occur every time the backup runs ?

Plex contains a huge number of small files. Maybe this is why it could be longer than downloading a single big file?

It may be related to the fact that you hard linking between different volumes. When you use the UI, are you doing the same thing ?

I got the same email. I've enabled two-factor authentication on my account and it did not affect the signing from the app.

If you want to point the watch folder to your main video storage, then make sure that the output folder is different. Once everything get converted, this output folder will become your main video storage... Make sure that "Non-Video File Action" is set to "copy".

Probably a cache issue. Try to clear your browser's cache.