rix

This has serious performance implications, though.

I still see this in 6.6.6. Assigning 16-20 GB slows down my VM boot up to 3 minutes... first boot is always quick.

This has helped me with my High Sierra VM. I was soo close to giving up. Thanks a lot!

I have just double checked. The config from the github readme is working fine for me. Make sure that the environment variables are set correctly to DOMAIN=example.com autoJoin=true webroot=slweb serverroot=slserver autoJoinServer=https://example.com/slserver so basically your nginx config will make sure that a local synclounge instance is served at https://example.com/slserver not http://example.com/slserver, not https://www.example.com/slserver double check DOMAIN and autoJoinServer if you set this up according to the readme, this is the most likely mistake.

Just restart the container afterwards. The interface will show again.

i have to update the docker image manually so it gets rebuilt, upon a new makemkv release. for editing the ripper script, see above.

havent heard of aiff before your request, so me neither. best I can do is lead you towards your goal. ripper will place a script (ripper.sh) at the /config volume this script is responsible for the automated ripping process. you can find the command responsible for creating mp3/flac files at https://github.com/rix1337/docker-ripper/blob/eb5b89bebd46306521701cd8129ab4df4156ec75/root/ripper/ripper.sh#L100 all you need is to modify that line on your local machine. how, I cannot tell you

Yes, just edit the script yourself to include an appropriate tool. Ripper contains merely an example of what to do.

Thanks for the advice. I now managed to set this up. Failed to understand the options.. 😅

lemme try to clear up the confusion. how would i set this up: -mover running daily to move all and any files to the array (regardless of space available on the cache) -mover running hourly to only move all and any files to the array if cache is > 90 % full i understand the options that setting the 90% limit will also affect the regular daily mover process..

Hi Squid, up until now I have used a custom script for the following: - Run mover at 3.30 am to move all movable files - Run mover script hourly to check if cache is at > 90% used I want to prevent my cache completely filling up. I would like to stop using a script for that, but as of now, this is unsupported by the addon, correct? Would be happy if you considered adding this. Kind regards

Yes, this container has nothing to do with the software itself. Its just the shell that runs JDownloader. Any software specific issues have to be dealt with by the JDownloader devs.

See https://github.com/rix1337/docker-dnscrypt/issues/4 To be reachable outside your container, you cannot use localhost, but instead 0.0.0.0. The best ressource on setting up the file is https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration This image does only care about the toml being placed at /config Hope that helps 👍

I tried these io limiters, as well as the kbps commands - which did not seem to have any effect. I am forced to set those limits for a specific device (/dev/sdX), the cache pool itself is not working (/mnt/cache/appdata). Since my containers use the latter, it is not working. Strange. Looking at my build, the old MX100 could be the culprit,.. I will try to remove it from my cache pool and do some unrar-stress testing. Has anyone else experienced this? Might be worth a more genereal thread..

Hi @Djoss, i have, what seems to be a hardware bottlenecking issue: When JDownloader starts unpacking downloaded files, the extremely high io takes the rest of my server with it. That is, my cache-pool seems to bottleneck hard, when files are extracted. Plex/nginx, even the webinterface of Unraid, are extremely unresponsive as long as the files are processed. Afterwards, everything returns to normal (so there is no crash/error). I have tried various commands to limit reads/writes of this container - to no avail. Do you have any idea how i could limit the containers iops to keep my system running? I have ruled out ssd temps as the issue, they are fine at ~40°C or lower.