hotio

You aren't even mounting the volume in unpackerr container?

You should configure your paths correctly as they are inside the container...

https://github.com/hotio/docker-unpackerr#configuration docker logs unpackerr on the CLI to view the log

and how long did you wait? if you think there's a bug, you should file a bug report with the app developer.

Your log file says otherwise...

You only need the source files for seeding, not the extracted files.

That's pretty much it.

Yes, it works without deluge. It monitors your *arr queue and extracts your files that need extracting, after the import is done it cleans up the extracted files.

Docs: https://hotio.dev Discord: https://hotio.dev/discord UPDATE: Please use the discord server (https://hotio.dev/discord) for support questions or any other question.

@SpaceInvaderOne thanks, that did the trick.

I'm running on a fully working ipv4/ipv6 network, however I've got "Network protocol" set to "IPV4 Only" on the unraid server. So afaik that's what you suggest.

"Remote tunneled access" gives an invalid QR code, because of a missing IP, only "/128" is put in the config.

yep, the ip address is missing from the config/qr

I've been messing with this for quite a while (or several hours atleast)...it seems that unraid's config page for the UPS is focused on USB attached devices. However I wanted to shutdown my UPS when using the Network Management Card and not USB. 1) Set the option 'Turn off UPS after shutdown' to 'No'. This only works when using a direct attached ups with usb or maybe serial. 2) Add the command "sed -i 's/\/sbin\/apcupsd/\/sbin\/apcupsd -p/g' /etc/rc.d/rc.apcupsd" to your go file "/boot/config/go". 3) reboot This will start "/sbin/apcupsd" with the -p flag (aka --kill-on-powerfail), this will instruct the ups to shutdown before the system is given the shutdown command. Since most SmartUPS's can have a shutdown delay set, this isn't a problem. Because the command is sent before shutting down the system, the network is still up and the ups is able to receive the request. Setting 'Turn off UPS after shutdown' to 'Yes', would execute "/etc/apcupsd/apccontrol killpower" at the very end of the shutdown sequence when the network is already down. Maybe there's some room for improvement here in how unraid handles this/does the config?

For anyone who cares... I've re-formatted the cache pool from encrypted-btrfs to just plain btrfs and the writes have droppped by almost 10x. Disk IO for [loop2] has gone from several GB's in a few minutes to maybe a 1GB in a couple of hours using iotop -a. Total writes for the SSD using LBA has gone to 1GB/hour, that is with appdata also on the same device. This will give a lifespan closer to 10 years instead of 1 year 🙂. Anyone real smart in here, that can explain the behaviour? I used to run LUKS encryption on the same drives with ext4 and /var/lib/docker straight onto the disk...this gave no issues. The combo LUKS+BTRFS+docker.img does however.

I know right.... I do use mover, downloads go to cache and then moved to array....but that's not the problem, I can see the GB's fly by with an idle system. And we certainly are not the only ones, lots of people seem to be having this issue, but every thread just stops dead in the water.

@Niklas Did you manage to find the cullprit of this nasty problem? I've got a 2 month old samsung 860 EVO 250GB that has almost 40TB written to it (god knows where the 40TB went....certainly not on the array). Stopping all docker containers seems to halt the continuous writing, the more containers that run, the more write IO I get. Several GB's/couple minutes, ssd wear level is already down to 89%. She sure is a silent SSD killer. EDIT: I notice you using "Cache: Encrypted btrfs. Array: Encrypted xfs." just like me, could the combo encryption+btrfs cause these massive writes?