PeterB

I find that the system temp plugin seems reluctant to load all modules, even if listed correctly (I think that the first listed is ignored). My solution is to modprobe the missing module in the go file.

Indeed, the inability to use NFS v4 is still an annoyance. I don't have any machines running Microsoft - all my desktop m/cs run Linux Mint, my KODI/LibreElec boxes run a Linux kernel, my Squeezeplayer boxes run a Linux kernel, my homebrew domestic lighting control system runs on Linux, even Android phones run a Linux kernel. Why would I want to run a microsoft network filing technology. T0rqueWr3nch has highlighted some advantages of using the latest version of NFS in such an environment. Please, if it's simply a matter of turning on a kernel option, and it has no adverse effect on any other functionality, can this be implemented in the next release?

I've seen this as well, but I only have eight cores. I see the CPU usage rise to near 100% and it's difficult to gain control. However, restarting the container restores sanity.

Thank you, sir, for the corrections. So containers do behave as though they have disk storage built in - if you modify that disk (image), the modifications will still be there tomorrow, after a reboot. But, if I understand correctly, if you modify a container setting, then the disk image will be reset to the state it was in the original distribution image?

I thought that the docker container image is loaded into memory, and that its system disk image is memory resident. If you write anything to that memory-resident disk, all you have to do to clear it is to restart the container. Yes, the docker vDisk image (where all the docker images are stored) can become full or, less likely, get corrupted during some system abberation. The vDisk is unlikely to become corrupted during normal system operation. As I understand it, Noego is concerned because he modified the container's disk image. Therefore, all he needs to do to get back to pristine state is to restart the container.

I have my dockers, and their data, on an unassigned drive. I download my torrents (leeching), initially, directly onto a cache-only share. Once the download finishes, and the torrent starts seeding, the torrent is automatically moved to a normal parity -protected share on array disks. I then do some processing, manually, using MKVToolNix, to place the manipulated movie file on to my Movies share. When I've completed that, I use deluge to move the torrent onto a another share on array disks. In this way, I can martial my torrents and know which ones I've created a movie file from. Duluge only ever writes torrents to the cache drive, without use of the parity drives. Once the torrent file is no longer being updated, it is moved to a parity-protected share for greater protection.

Strange - I have the problem that I no longer have 'update' options showing on the Dashboard - I have to go to the Docker page in order to invoke the update.

AutoRemovePlus: As far as I can tell, the most active/recent development of the AutoRemovePlus plugin is being performed by Spring Jools, here. I've even had correspondence with the maintainer, and had a new feature added. I downloaded the .zip, and built the .egg within the docker container (Latest). I installed it, taking note of the advice at the bottom of the README.md, to delete existing versions and .conf files. It appears to work perfectly well, but can only be configured from the Deluge WebGui. I have built, and installed, it on my desktop computer for the Thin Client but, while it appears to install, and can be enabled in the plugin preferences, I cannot get the actual AutoRemove settings to show up there. So, although the plugin can only be configured through the WebGui, it does work.

These ar e the type of problems I was experiencing a couple of weeks ago. I tried several of the European servers - in the end, I discovered servers in Canada appeared to be working correctly. When my year subscription is up, I will look at moving to Mullvad.

After three years of using PIA, I had a problem last week, getting a decent connection. I tried several servers and experienced different symptoms with the various ones I tried. In the end, I discovered a Canadian server which was, and still is, working okay.

Ah, that was just off the bottom of my browser window. Okay, that has done the trick - thanks.

I have been selecting default colours, I have clicked the reset button, and the machine has been rebooted. What else can I do to gain control over the colours? See attached screenshot. Disks 1-8 are data drives, Drive 12 is unassigned (used for docker).

What do you call "full speeds"? My connection is, at best 100Mbps (nominally 50Mbps), and I am still seeing downloads at up to 8MBps and uploads running at the full limited rate of 6MBps, with v2.0.4.

But my Data drives are shown in a darker blue, and this colour doesn't appear in the picker.

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.