PeterB

See my post above - try reverting to 2.0.3-1-08 of the docker.

Reverting to 2.0.3-1-08 appears to have fixed the problem.

I've noticed, over the last couple of days, my unRAID server running at 99% memory usage and the UI becoming unresponsive. Yesterday I rebooted the whole server but, 24 hours later, I'm seeing the same problem. Now I discover that if I restart DelugeVPN, the memory usage drops back down to less than 30%, but then creeps up again. Looking in deluge logs, I see repeating series of entries including the line mentioned above: As far as I'm aware, deluge has been at v2.03 for a few months now, so how come this has just started happening?

My Linux Mint client reports 2.0.3-2-201906121747-ubuntu18.04.1

Your LAN_NETWORK is set to 192.168.1.0/24 yet you're trying to access 192.168.100.*. Change your LAN_NETWORK to 192.168.100.0/24.

Weird - I wonder why it's stopped working, then?

Ever since the Deluge V2 upgrade (weeks, or even months, ago) I have been using the AutoAdd plugin to load torrents from CouchPotato (using the BlackHole mechanism). For some reason, around a week ago, this stopped functioning - the .torrent files are written by CouchPotato, but Deluge no longer seems to respond to them. To the best of my knowledge, I've not made any configuration changes, and CouchPotato certainly hasn't received any updates. Has something changed in DelugeVPN which might be responsible?

If so, the files will vanish if you stop/restart the image.

Okay, I've worked out how to do this. I've set the "/media" path to point to the directory containing links. Then I created a new path pointing to the directory containing all the photos (in sub-directories), with container path "/files". Now I can create links as: ln -s /files/DirectoryOfPhotos DirectoryOfPhotos in the /media directory. I can create the links either from the container console or from an ssh session to the unRAID server or from the console on my desktop machine (in each case with the media directory as my current working directory). I think that the important point is that the link from "/media" points to "/files....". My reason for wanting to do this is that I wanted a single share in which to hold/archive all my photos but didn't want them all to be visible to minidlna. This way minidlna only offers the photos suitable for viewing on my photoframe.

Is there a way to make minidlna follow symbolic links in the /media directory? I want to point /media to a directory containing only symbolic links to the directories where the photos are located. Even though I have set "wide_links=yes" in minidlna.conf, a scan does not find my photos. Indeed, 'ls' within the the container console does not list the files contained within the linked directories. sh-4.4# ls -l /media total 92 lrwxrwxrwx 1 nobody users 40 Sep 13 09:34 170708_E-Park -> /net/tower/mnt/user/Photos/170708_E-Park -rw-rw-r-- 1 nobody users 90551 Apr 10 2018 29497761_918176058363228_5695819176497643520_n.jpg lrwxrwxrwx 1 nobody users 55 Sep 13 09:33 'Link to 180408_Cling_YWAM_Graduation' -> /net/tower/mnt/user/Photos/180408_Cling_YWAM_Graduation lrwxrwxrwx 1 nobody users 38 Sep 13 09:33 'Link to 180418_VBCS' -> /net/tower/mnt/user/Photos/180418_VBCS lrwxrwxrwx 1 nobody users 49 Sep 13 09:33 'Link to 190519_UpsideDownHouse' -> /net/tower/mnt/user/Photos/190519_UpsideDownHouse lrwxrwxrwx 1 nobody users 50 Sep 13 09:33 'Link to Methodist Youth Surigao' -> '/net/tower/mnt/user/Photos/Methodist Youth Surigao' sh-4.4# ls /media/170708_E-Park/ ls: cannot access '/media/170708_E-Park/': No such file or directory sh-4.4#

My solution is that torrents which are leeching are held, unprotected, in a folder on the cache drive (but a folder on UD would be just as good). When the torrent finishes downloading, deluge moves it to a folder on the protected array. In this way, the parity drive is only involved during the nightly copy of newly completed downloads from cache. If the cache drive were to fail, I would only lose currently downloading torrents, which could be easily restarted. This has been working well for me over many years.

That's odd! As I understand it, that has to be a problem with the VPN tunnel being established. If the VPN is down, all connections are disabled. Why that should change between the two releases is a puzzle. I would try re-configuring all the docker/container settings - particularly those around the VPN. Sorry, I'm lazy to go back through your posts - is there anything odd at all in the container log relating to the VPN? Yes, I'm using PIA, currently on the Czech endpoint.

I didn't have to alter any docker configuration, and the web UI works fine. Have you tried clearing browser cache, etc.

Indeed, I have been using deluge v2 for just over a week, and it is running just fine. The thin client is working well - but I do run Linux for my desktop. I like all the new features - a welcome upgrade! I also use the CouchPotato docker and have it set to use Black hole to upload torrent/magnet files to deluge - it does everything I need.

I'm not using Black Hole but, since the deluge interface from CouchPotato no longer works with deluge v2, I have set CP to use the BH method of sending magnet/torrent files to deluge V2. Simply configure the 'AutoAdd' plugin in deluge to find the magnet/torrent files.

I've just noticed that my deluge wasn't reporting any transfers. Test active port was failing too. I restarted the container, everything is back running. I found this: in the log. I'm guessing that it all stopped at: 2019-06-26 09:11:29,128 DEBG 'watchdog-script' stderr output: Unhandled Error

All plugins will have to be modified/re-written for the new application interface, and converted for Python v3.7

Preferences -> AutoAdd

The new deluge release adds a number of facilities over v1, which had been untouched for some years now, and improves performance considerably. I, for one, am extremely happy to have v2 available. Clearly, the system interface has changed and caused many incompatibilities - I'm happy to have a workaround for CouchPotato. The other major drawback at the moment is that the Windows version is not yet complete, so those who use Windows on their desktop don't have a thin client available (but the webUI should be good).

Well, for the time being, I have set CP to use Black hole as the downloader, and configured 'AutoAdd' in Deluge. That seems to be working but I had to enable 'Magnet File' in the CP Black hole downloader section. Obviously, you have to have the same path added in both containers so that they share a folder for writing/reading the torrent/magnet files. I recommend this for anyone who wishes to retain CouchPotato while moving to the updated deluge.

The v1.3 gui/console is not compatible with the v2.03 daemon, so no surprise that doesn't work. The v2.03 console (thin client) works well with the v2.03 daemon - again, shouldn't be a surprise. However, if you run your desktop computer on Windows, you're out of luck because the v2.03 conversion to Windows isn't complete yet. For me, the web gui and/or the thin client work well for me on my Linux Mint desktop. My big problem is the couchpotato/deluge v2.03 incompatibility.

Thanks for your effort on this, but I still get "Connection failed. Check logs for details" when I click on the 'Test Deluge' button in 'Settings -> Downloaders'. I look in the logs and I don't see anything relating to the problem.

Okay - it would be a shame to loose CP. I still cannot accept the fact that sonarr/radarr enforce one movie per directory. Using .mkv containers eliminates the need and fs overhead. Yes, I found the radarr and sonarr issues that you identified. I did try forcing deluge to create a new ssl certificate, but that wasn't the issue.

Upgrade to the deluge v2.03 version appears to have completed without major incident. I did take a prior copy of the deluge appdata folder, but it wasn't needed. Deluge v2 doesn't appear to have hit the mint/ubuntu repositories yet, so I went to the deluge ppa to upgrade my thin client. All working well! Edit: One oddity to report. I have the scheduler enabled, and everything I'd done with upgrade and testing had been during a 'slow speed' period. I noticed that, while uploads had been running, I hadn't seen any download activity - downloads only started running when I set the current schedule period to 'high speed'. After that, I set back to 'low speed' and downloads continued running. Oh, and others have reported, I don't seem to be able to get the CouchPotato connection to Deluge working (from the Binhex CP docker).

If you read the release notes for deluge v2, you will see that v1 plugins will need to be modified/re-written.