Djoss

The maintenance license only allows you to get support from code42, but doesn't prevent the software from working. It's not the same thing as the license key, which is needed to unlock the software.

Is this version as working fine before ? If yes, then probably there is something else (than the docker container) that is causing the slow rip.

Same thing, try to load the previous Docker image version, or the one before, to see if the speed returns to normal.

Did you try an older version of the image to see if it's working again ? Also, were you using the latest version of the image ? Looks like a similar problem has been resolved with the latest version of MakeMKV: https://forum.makemkv.com/forum/viewtopic.php?f=3&t=28636

New image available!

Are you using default container settings? Usually, the path /mnt/user/... doesn't exist inside the container. By default, /mnt/user is mapped to /storage inside the container. So you will find your Media directory at /storage/Media in the container. Also, by default /storage is read-only. You have to edit the container setting to change it read/write (Advanced view must be enabled for that).

You may want to try the debug version to see if more information can be retrieved from the conversion log. Just use the tag "v1.25.1-debug".

Can you try to "touch" any file in the watch folder, or add a new one ? This should kick the automatic video converter again. BTW, the log from the web interface is incomplete. You should run the "docker logs HandBrake" command to get all its content.

If you prefer it's probably better to revert to the previous version, by changing the "Repository" in settings to: jlesage/handbrake:v1.24.2 But before doing so, can you please share the full log by running: docker logs HandBrake

By default it should run every 5 seconds, but maybe the interval has been changed. You can check its value by looking at the "Automatic Video Converter: Check Interval" container setting.

In the first log messages you posted, there are a bunch of files that were skipped. If you wait for the next run, do you see the same messages ? Also, is the watch folder a standard unRAID share ?

It's a uppercase "B": HandBrake.

Are your files readable ? What is the output of the following command: docker exec HandBrake ls -l /watch

Ok I see. The container is based on Alpine Linux, meaning that the binary you compiled is not compatible. You either need to compile has a static binary or compile it under Alpine Linux.

What is this executable exactly ? Is it a script ? If yes, which shebang it is using (the first line that begins with #!....)?

Did you try to remove and re-install the container ? I know that in the past, there was an issue when changing the network mode, causing the container to not be configured correctly.

In bridge mode, what do you have exactly when you try to connect ?

Maybe a permission issue ? Can you share the output of "docker exec JDownloader2 ls -l /output/extract-xiso" ?

How did you configure the container ? Are you using the default Bridge network mode ?

Looks like a network issue. Can you run the following command to see if the DNS resolution works from the container: docker exec CrashPlanPRO nslookup central.crashplanpro.com

What are the errors now in service.log.0 ?

It may still worth a try: if you copy a big file to the watch folder, it will take some time. So the watch folder needs to wait for the copy to complete before processing it.

This is not something currently supported. However, could you rip directly to the watch folder ? Is it smart enough to not start the transcoding until file is "stable" ?

Do you see the "[cbbLocalManagement] starting..." message repeating in loop ?

Can you add a feature request at https://github.com/jlesage/docker-handbrake/issues ?