PeterB

Thanks for the response. Yes, I do have directory caching enabled. Researching possible conflicts, but not found any information yet. UPDATE: It appears that this issue is being caused by the BinHex Couch Potato docker.

Just upgraded from 6.8.3 to 6.9.0 today. Now, none of my drives are spinning down. Openfiles doesn't show anything open on the drives I would expect to see spin down, but something is reading from them (~20k reads on each drive, in a little under ten hours). Turbowrite is disabled (Data drives spun down: script not running, Write mode: unraid determined). How do I identify what is accessing the drives in question? Should I revert to 6.8.3?

I've just (ten minutes ago) loaded the latest update, and the AutoAdd plugin seems to be working once again.

Is anyone else using the AutoAdd plugin? It used to work a treat for me but, sometime recently, it has stopped recognising new .torrent files. I don't think I have changed any settings but, in any case, changing settings shouldn't stop it recognising new files entirely. It cannot be an installation problem since AutoAdd is a 'standard' plugin - part of the Deluge distribution. I would love to have it working again - any ideas/suggestions?

So why does mine keep creating (corrupt) .torrent files?

I must be missing something - for the life of me, I cannot see where/what to set to use magnets.

I have posted some of this info in a reply in the delugevpn thread, but I think it really belongs here. I find that the Jacket rarbg fetcher sometimes fetches a 1.3kB file containing html which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once, then the next time it fails again. In case it makes a difference, I'm using Jacket with CouchPotato. Has anyone else encountered this or, better, found a solution. I've never had any success with the 1337 or isohunt fetchers.

I'm not sure whether it is the same issue, but I find that Jacket sometimes fetches a 1.3kB html file from rarbg which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once then the next time it fails again. Further, testing a fetcher from within Jacket seems to set the watch inactive in the deluge AutoAdd plugin.

Okay, so I left the WAN for port 1337 redirected for more than an hour. This time a /tmp/portfailure file popped up (no /tmp/dnsfailure), but even that disappeared when I re-enabled the WAN, and everything started running again.

So, I reset the port 1337 route back to WAN2, the 'dnsfailure' file disappeared and torrents have restarted - exactly as intended. Hmmm .... what else?

Scrub all the following - the 'dnsfailure' file has just appeared! Ah, I've just realised that this probably won't work. If the dns query isn't going via the tunnel, then simply changing the routing for the tunnel won't cause it to fail. This may have something to do with why I'm experiencing this issue - let me explain .... My main internet connection is unmetered fibre on WAN2. If that connection goes down, I (manually) revert to a metered LTE connection on either WAN3 or WAN4. I don't want to use the metered (PAYG) connection for torrents - first of all, it is much slower and secondly, relatively expensive. To prevent torrenting via LTE, I have a route set up so that any traffic from Tower to destination port 1337 will only go via WAN2. However, if I bring up WAN3 or WAN4 the DNS query will still succeed and failure may or may not be registered, depending on how soon I (manually) bring the alternative WAN into use. I suspect that you are correct, though, that deletion of the temporary file may be failing. To test, without taking the rest of my network offline, I guess that I will have to route all Tower traffic to the unconnected WAN. This will stop my email and a few other services for a while, but shouldn't cause a major issue. Just to confirm, the dns query will go to the configured NAME_SERVERS (currently 1.1.1.1 & 1.0.0.1), and not to my local dns server?

Too late - I'd already restarted! I'll try replicating the problem .... If I change the routing so that the tunnel goes to an unconnected wan, it should have the same effect as Internet outage.

Yes, I'm using wireguard now. As far as I can tell, the Internet went down around 10:32 on Jan 23 and it came back around 8pm on Jan 24. I cannot see any change in behaviour to indicate that the docker was aware that the Internet service had returned. supervisordCopy.log.zip

Hey @binhex Some time ago I reported an issue where the tunnel didn't automatically re-establish after a length period of Internet outage. You identified a change which might address the issue. Unfortunately, the problem still appears to persist. We had an Internet outage which started around 11am on Saturday and it came back around 8pm on Sunday. The deluge vpn still doesn't seem to be back up, almost two hours later. I'm sure that the vpn will come up if I restart the container. I have taken a copy of the supervisord.log - unfortunately without debug turned on. I can send it if it might be of use to you. If needs be, I could try to reproduce the problem artificially, with debug enabled.

Okay - I refuse to use radarr because I hate having a new folder created for each movie - what's the point? It seems ridiculous, to me, to maintain a lot of folders, each with just a single mkv file which, as far as I'm aware, is still enforced by radarr. If radarr handles the separation of incomplete and complete folders, then fine - as long as you don't mind unnecessary nodes in your file structure.

Much better to define new container paths, then you have more control of where the various folders are. I have my 'incomplete' on a cache-only share and my 'complete' on a protected share.

I always post-process my downloads, for instance, to add subtitles into the mkv or change parameters, synchronise tracks - that's when I make a copy of the mkv in my Movies or Series shares. In any case, I wouldn't want to upload from the same location as my library.

Deluge has a very functional "move on completion" facility. Look in Deluge -> Preferences -> Downloads. No script required. Doing the move from deluge ensures that the torrent continues to seed. It works for me! /LeechTorrents is a 'cacheonly' share. /Torrents is a normal, protected, share.

Have tried just putting the modprobe command into your go file?

To the best of my knowledge, all releases of this docker container, for the last several months, have been based on Deluge v2.0.4.dev38. This would include all builds implementing PIA 'nextgen'. One question for Binhex to answer - what would happen if we went into the running container and used apt to install an alternative version of deluge?

Ooo, this has just prompted me to look at the TrueNAS website. Promises NFSv4 support! Perhaps, after more than ten years using unRAID, and putting up with regular failures with NFSv3 shares, it's time to consider moving on!

Yep, working for me, now. Many thanks, sir!

Still failing with 1.1.1.1,1.0.0.1

Sorry - with Debug on! DelugeVPNLog.txt

Latest is failing for me - PIA/Wireguard It just hangs, seemingly for ever. DelugeVPNLog.txt