PeterB

I run the deluge thin client on the Linux Mint desktop - that will intercept magnet links and direct them to the deluge server.

Something odd has happened to my colour picker and I'm not sure what/why or how to resolve it.

Great! Many thanks - all good now.

This update has messed up the display of available disk bays in the Dashboard display. Slot number is too low, LED is too high.

Thanks for that. I can get the configuration interface to come up in the web client, but not in my thin client (running v2.1.1.dev7501). Perhaps I need to find a 2.0.4 thin client for Linux Mint.

Yes, it is possible - I don't actually use the /data directory. I have three separate folders, on three different shares, for leeching torrents, completed torrents and post-processed torrents, like this (simply create new container paths):

If you look in the delugevpn logfile, I think you'll find that it has filled up with many occurrences of I'm hoping that Binhex will eliminate these errors by building the docker with the previous version of Python.

Take a look at the 'downgrade' utility - available on AUR.

Would it be unreasonable to force the docker to build with Python 3.7, for the time-being? Progress on deluge v2.04 appears to be slow, so I would suspect that we are stuck with v2.03 for a little while.

This problem has affected every release since 2.0.3-1-08. I suggest that you roll back to that version.

Have you recently updated your deluge docker container to one which includes deluge v2? If so, CouchPotato does not implement the new V2 deluge interface. You have to set CouchPotato to use the 'Black hole' protocol and use the AutoAdd plugin in Deluge. I've been working like this for months.

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.