raiditup

I've noticed for the past few weeks that whenever my docker containers are stopped by Appdata Backup/Restore for backup, when they come back up, no torrents old or new work. On the binhex-delugevpn console, I can ping out, but no torrenting works unless I restart the container again. Has anyone experienced this?

You'll probably need to grab the Source code from the plugin developer and recompile the plugin inside the console of the delugevpn container.

Glad you got your speeds back!

If you're using Deluge 2.0.0 and up, you have to use plugins that were rewritten for the newer releases. Any plugins written for Deluge 1.3 will not work in 2.0 and up. If you do have an up-to-date plugin, you can install them through the Deluge WebUI under Preferences -> Plugins and then click the Install button. You can also put the .egg file directly in the plugins folder of your docker container e.g. /mnt/user/appdata/binhex-delugevpn/plugins

I believe you need a comma after the "Label". If the container fails to start, it usually will say why in the logs. "enabled_plugins": [ "Label", "ltConfig" ],

I had that problem too. Before you do this next step to fix that issue, make sure you stop the delugevpn container in the unRAID webGUI. After delugevpn is stopped, edit the core.conf file in /mnt/user/appdat/binhex-delugevpn/core.conf nano /mnt/user/appdat/binhex-delugevpn/core.conf Change the "enabled_plugins" setting to the following "enabled_plugins": [ "ltConfig" ], This should enable the plugin on startup.

The 2.0.4 label is either a typo by the dev team or is an early beta of 2.0.4. In any case that version, it's the version I'm using and it works with the ltConfig plugin. To get the plugin working, you'll need to compile it from scratch using the python version that's used in the container. Instructions On the same page you tried download the .egg from, https://github.com/ratanakvlun/deluge-ltconfig/releases instead download one of the compressed Source Code files. Extract the folder and copy or scp it to the plugins folder of the delugevpn container. e.g. /mnt/user/appdata/binhex-delugevpn/plugins on your unRAID server. Now go to the webGUI of your unRAID server, click on the Docker tab, click on the icon of the delugevpn container and open the Console. In the console, go to the Source Code folder you just uploaded in the plugins directory which will most likely be in /config/plugins. Then compile the plugin. cd /config/plugins/deluge-ltconfig-2.0.0 python setup.py bdist_egg The compiled egg will be located at /config/plugins/deluge-ltconfig-2.0.0/dist/ltConfig-2.0.0-py3.8.egg. Copy it to the root of the plugins directory. cp /config/plugins/deluge-ltconfig-2.0.0/dist/ltConfig-2.0.0-py3.8.egg /config/plugins You may need to restart your delugevpn container after this, but the plugin should now show in the WebUI of Deluge. In the Deluge WebUI, go to Preferences -> Plugins and enable the ltConfig plugin. A new ltConfig menu option will become available inside Preferences. Click ltConfig and make sure "Apply settings on startup" is checked. Scroll down the menu until you locate enable_outgoing_utp enable_incoming_utp Make sure these two settings are unchecked and Apply the changes. Restart the delugevpn container one more time and double check that the ltConfig plugin loaded on startup and the two settings are unchecked. Enjoy your faster torrent speeds again.

This has been an ongoing issue for a lot of users of PIA and Deluge. You need to install a Deluge plugin called ltConfig, but unfortunately it doesn't work with the latest version of Deluge (2.0.4), which the docker is currently on. Your only option is to rollback your docker container to the last release of 2.0.3, binhex/arch-delugevpn:2.0.3_23_g5f1eada3e-1-03 and reinstall the ltConfig plugin. The process is a little involved because it requires compiling the beta version of the ltConfig plugin (2.0.0) inside of the docker container. Once the plugin is installed and activated within Deluge, you need to disable the following two settings within the ltConfig settings and your torrent speeds will be back to normal. Uncheck These enable_outgoing_utp enable_incoming_utp If you need help with any part of this process, let me know. I know how frustrating it can be.

Well that's great for you, but for people like me who see a dramatic decrease in speeds without the custom settings that the ltConfig plugin provides, you should rollback to version 2.0.3. Without it, I see at most 1MBps down and with it, downloads jump to 35-40MBps so that's what I consider "full speeds".

For those of you using PIA and have had their torrents stop working recently, I've found the beta version (2.0.0) of the ltConfig plugin doesn't work with Deluge 2.0.4 which is what the latest docker release is on. Like another user, I created a brand new docker container which allowed my torrents to start working again, but my speeds were slow. When I compiled and installed the ltConfig plugin in the new container, the torrents stopped working again. At this point if you want PIA working with full speeds, your only bet is to roll the docker container back to Deluge 2.0.3. You can do this by stopping the container and editing the repository setting to point to the last 2.0.3 release. The container will automatically rollback to the specified version. The repository should look like this, binhex/arch-delugevpn:2.0.3_23_g5f1eada3e-1-03

For those of you using PIA for VPN and have been waiting for the ltConfig plugin to be available for Deluge 2.0, the maintainer has released a forked beta version. You'll need to compile the plugin yourself in Python 3.7 for it to work however. ltConfig Beta Version -> https://github.com/JoshDi/deluge-ltconfig To ensure the plugin was compatible, I actually compiled it directly within the latest binhex-delugevpn container and then copied the resulting .egg to the binhex-delugevpn plugin directory on my unRAID host. After restarting delugevpn, I was then able to enable the plugin and disable/uncheck the following settings. Make sure to also check "Apply settings on startup". enable_incoming_utp enable_outgoing_utp Once these two settings are disabled, my torrent speeds skyrocketed back to where they should be. If anyone needs help with this process or would like me to just post the pre-compiled plugin, let me know.

Yeah webUI worked for me too, but not able to connect directly to the daemon.

Log into the Unraid WebGUI and click on the Docker tab Click on the binhex-delugevpn app and click Edit Change the Repository to binhex/arch-delugevpn:1.3.15_18_ge050905b2-1-04 and click Apply. You should then be automatically reverted back to the last version before it switched over to 2.0.3

Has anyone been able to connect to the deluge daemon running on 2.0.3? I've tried with the 1.3 gui & console and the 2.0.3 console and I see libtorrent errors. As soon as I revert back to 1.3, it works again.

I found a workaround for now. If I edit the VM's config in the GUI and switch to XML View, I can change the settings of an existing network interface to point to the bridge I created. <source bridge='br0'/> Change to <source bridge='prv0'/> Still holding out hope that unRAID will make all interfaces visible to the VM's.

Hi, A year ago or so, I created 2 private bridges in libvirt for VM testing purposes. These bridges are persistent and active, but they no longer show up as an option when creating or editing my VM's. I'm wondering what may have changed in the many updates unRAID has gone through since I first created these bridges and how I can make these bridges usable again. I've already run virsh net-list to confirm the default bridge and my 2 private bridges show up as Active and Persistent, but these bridges do not show up in the GUI network or VM settings. Anyone got any ideas?

No disk shows up in the Clover menu.

Yeah I created a .img from the USB. The only difference is I used an Ubuntu machine to create the img with qemu-img instead of plugging in the drive directly to the Unraid server. I then scp'd the img file over to the Unraid server. I followed both the Creating Install Media and the How to High Sierra on Unraid videos by Gridrunner but still ran into the issue of it not seeing the disk.

I'm having the same problem as you. I've tried the latest version of Clover (r4380) and the one suggested in the description of the Creating Install Media guide (r4220) and both times Clover sees no disk.

I found this article on a blog site that explained why this isn't working in the latest version of unRAID http://kicherer.org/joomla/index.php/en/blog/48-automatic-hotplugging-of-usb-devices-for-libvirt-managed-vms It appears that when you run a command fired from a UDEV rule, the rule waits for the command to finish before completing the event such as mounting or attaching a USB device. This is why my attach command kept failing as my USB device wasn't attached when it ran. The clever blogger was able to workaround this issue by using systemd to run his command. Unfortunately, unRAID is based on Slackware which still uses init so I instead wrote 2 scripts for each USB device. One to attach/detach the device and another to call that script. My UDEV rule now fires the 2nd script which calls the real script. The call script looks something like this #!/bin/bash /boot/config/attach-keyboard.sh & disown The key is the call script includes "& disown" which will run the script in the background and disassociate it from the shell. Theoretically I should've just needed the "&" but it still didn't appear to work without the disown. This allows the UDEV rule to not wait for the script to finish running before attaching the USB device. I'm sure there's probably a cleaner way to do all of this, but this is what has been working for me. I'm going to try and write an article on my blog and will post a link when I'm done. In the interim, if anyone needs more info on how to automate USB Hotplugging for VM's, I'll be more than happy to help.

Sorry originally posted this in the general forum thread. Before I updated to the latest build (6.3.2), I had a custom udev rule copied to /etc/udev/rules.d on boot. It allowed me to use a mouse and keyboard hooked up via KVM like USB switch to be shared between my main PC and a VM in unRAID. On the latest build however this doesn't seem to work anymore. I can attach the mouse and keyboard manually when switching between my PC and VM but this is a major hassle. I'm not sure if its an issue with the latest version of libvirt or udev that's causing the problem. If anyone has a custom udev rule working in the latest build and can provide assistance with this it would be much appreciated.

Sorry this was posted in the wrong Forum. Can this be deleted?

Before I updated to the latest build (6.3.2), I had a custom udev rule copied to /etc/udev/rules.d on boot. It allowed me to use a mouse and keyboard hooked up via KVM like USB switch to be shared between my main PC and a VM in unRAID. On the latest build however this doesn't seem to work anymore. I can attach the mouse and keyboard manually when switching between my PC and VM but this is a major hassle. I'm not sure if its an issue with the latest version of libvirt or udev that's causing the problem. If anyone has a custom udev rule working in the latest build and can provide assistance with this it would be much appreciated.

Thanks for the quick turnaround. Sickrage is back to functioning as normal.

I was wondering if the current release is off the latest Sickrage build. I'm getting a timezone error in Sickrage and the Sickrage creator says on his Github page that its fixed in the latest build.