Djoss

Do you have the issue when ripping 1 or 2 discs at time ?

Which browser are you using ? Do you have the same issue with another one ? Note that these kind of problems can also be created by browser's plugins/extensions.

Having a message about the upgrade failure is expected. However, it should not re-appear after you close it.

Do you know where are coming these files ? Are there created by another container ? If yes, it might be incorrectly configured. Note that to restore default permissions in shares, you can use Tools->"Docker Safe New Perms".

When you edit container's settings, the output directory is defined by the value of the "Output Directory" configuration element.

Is this fixed with the new image ?

There is a new version of CrashPlan available. I'm working on this and a new image will be released soon. However, I'm not sure why this prevent you from accessing the interface. Do you usually have to enter your username/password every time you access the interface ?

What are the ownership and permissions of theses files ? If the related containers run under a different user as CloudBerry Backup, it is possible that it doesn't have access to the files.

Yes, this is expected since the current beta key is expired. We need to wait for the MakeMKV author to publish a new key (or you can buy one if you want to avoid these troubles).

You can try to open a new tab and start a stop watch at https://www.online-stopwatch.com/. This will at least confirm that there is no issue with Firefox itself.

Also, are you sure it's not the site itself that has an issue when kept open for too long ?

It's probably an issue with HandBrake itself...

Sorry I'm confused. Is the PC your are shutting down the one running the container ?

Did you check if symlinks were broken inside the container ? docker exec CloudBerryBackup ls -l /storage/user/backups/AWS_Syncs If symlinks are using pointing to absolute paths, they could be broken inside the container.

I'm not sure these indicate real issues. Check instead the output of "docker logs Firefox".

I would also check the container's log to make sure the behaviour is not caused by the container restarting or Firefox crashing.

Forgot to reply here, but nightly builds are working again.

Then I don't know how this is possible. So you see the same behaviour with default container and Firefox settings ?

You can try to add something like "proxy_read_timeout 60s;" (adjust the time yo your need) to the Advanced section of your proxy host.

If you open a web page in Firefox and then don't touch the container, the page will stay there forever. Are you saying that you see Firefox closing/exiting itself ?

Are you using a reverse proxy? This is usually the one causing the disconnection.

Support for Tixati docker container Application Name: Tixati Application Site: https://tixati.com Docker Hub: https://hub.docker.com/r/jlesage/tixati Github: https://github.com/jlesage/docker-tixati Make sure to look at the complete documentation, available on Github ! Post any questions or issues relating to this docker in this thread.

Did you try to paste with "Ctrl-v" ? If that doesn't work, can you provide an example of what you are trying to copy/paste ?

This is because the "Plex Media Server" folder is part of the internal CrashPlan exclusion list...

Looks like a network issue. Are you able to manually access https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz ?