[Support] binhex - qBittorrentVPN


Recommended Posts

I've got an issue that is absolutely driving me crazy. I've got something going on with Unraid where it just reboots out of the blue. THAT is another story.....BUT...the result is that qbittorrent config settings revert to defaults which means when Unraid comes back up and the array starts, qbittorrent starts moving all my completed and incomplete torrents to my SSD cache, which I DON'T want!!! It is a nightmare to have to try and get everything fixed and moved back around afterwards.

Does anyone have any idea why the settings revert back to default? I stop the qbittorrent docker quite a bit and backups are run every night which means all the data should be flushed to disk and permanent, so I'm trying to figure out what it is that causes the revert to default and a way to stop it.

Thanks!

Link to comment
2 hours ago, binhex said:

edit - actually the data DOES disappear from the config file once you have logged in after a restart of the container, no idea why that would happen!. certainly not something i am actively doing in this container.

Not sure if this is relevant but I’ve noticed that the creation date and modified date for the config file are constantly changing. It’s as if the app (or something else) is constantly overwriting the file. Every time I open the appdata/bittorrent folder via smb I see that creation date/time and modified date/time both show the current date/time. Pretty sure I haven’t seen this behavior with any of my other dockers.

Link to comment
32 minutes ago, jmbailey2000 said:

so I'm trying to figure out what it is that causes the revert to default and a way to stop it.

Thanks!

Why don’t you attach your docker run command and supervisord log to your next post to give everyone a little info on your setup. Be sure to redact users and passwords from both.

Link to comment

I'm switching off qbittorrent.

 

I just noticed corruption of files. qbittorrent says a file is 100%, then I watched, and there was a slight, albeit noticeable corruption. So I went went back into qbittorrent, forced a recheck,  99.8% complete. Make a copy of original, restart the "uncompleted" version, it finishes, I "force recheck" one more time just to be certain... 100% ... I sha256 the original and newly fixed file, different hash so obviously something went weird. Plus the newly fixed file no longer has the corruption. I went and checked about 2 dozen other completed torrents, 3 others were also similarly broken.

 

Granted I've got literally several DOZENS of torrents in all the stages of queuing, and downloading, so maybe its got some code that doesn't like tracking that many files at one time. A threading/multitasking problem in the code?  With what binhex replied to me above, it just seems qbittorrent, for all its bells and whistles and features, has WAY WAY WAY too many bugs filed. All I really need is a stable download manager that sits in the background and downloads what I tell it to.

 

PS: No, its not my hardware, I've memtest the crap out of it in the last 2 months, its an otherwise stable Xeon box with ECC ram running a few VM's.

 

Going to try binhex/delugevpn :)

Link to comment
20 hours ago, binhex said:

 ok i had a poke about and it looks to be saving to the correct location, for instance adding in two trackers writes to the file:-


/config/qBittorrent/config/qBittorrent.conf
line 9 - Bittorrent\TrackersList=test\ntest2

but as you have correctly identified, if you reboot then this is disabled and the list is shown as empty in the web ui, BUT the config is still present in the config file. So i would def say this is a bug in qbittorrent, most probably a new bug introduced after 4.1, as you said it wasn't present in that version.

 

edit - actually the data DOES disappear from the config file once you have logged in after a restart of the container, no idea why that would happen!. certainly not something i am actively doing in this container.

ok i got some good news and some bad news, the good news is ive identified what is causing the setting to be removed, the bad news is that in order to fix this it will break the ability to set the incoming port in qbittorrent :-(.

 

so the problem is caused by the api, as soon as we set the port it resets one/some settings in the web ui, i think this is a bug in qbittorrent so i will raise it as such on their issue board and see what happens, im hoping for a workaround as the only other way to set the incoming port is to kill the qbittorrent process, hack the config file and start qbittorrent - every time the port changes!, not a nice prospect.

 

Issue raised:- https://github.com/qbittorrent/qBittorrent/issues/13585

Edited by binhex
  • Like 1
Link to comment
3 hours ago, binhex said:

ok i got some good news and some bad news, the good news is ive identified what is causing the setting to be removed, the bad news is that in order to fix this it will break the ability to set the incoming port in qbittorrent :-(.

 

so the problem is caused by the api, as soon as we set the port it resets one/some settings in the web ui, i think this is a bug in qbittorrent so i will raise it as such on their issue board and see what happens, im hoping for a workaround as the only other way to set the incoming port is to kill the qbittorrent process, hack the config file and start qbittorrent - every time the port changes!, not a nice prospect.

 

Issue raised:- https://github.com/qbittorrent/qBittorrent/issues/13585

Great, at least you narrowed down the issue!

 

Is it possible to use the API to change the trackers and have them stick after the port change?

 

A nice feature to have in general would be the ability to add a list of trackers that would be updated automatically anyways. This feature is available in several other torrent programs but not qbittorrent for some reason.

Link to comment
9 hours ago, mooky said:

I'm switching off qbittorrent.

 

I just noticed corruption of files. qbittorrent says a file is 100%, then I watched, and there was a slight, albeit noticeable corruption. So I went went back into qbittorrent, forced a recheck,  99.8% complete. Make a copy of original, restart the "uncompleted" version, it finishes, I "force recheck" one more time just to be certain... 100% ... I sha256 the original and newly fixed file, different hash so obviously something went weird. Plus the newly fixed file no longer has the corruption. I went and checked about 2 dozen other completed torrents, 3 others were also similarly broken.

 

Granted I've got literally several DOZENS of torrents in all the stages of queuing, and downloading, so maybe its got some code that doesn't like tracking that many files at one time. A threading/multitasking problem in the code?  With what binhex replied to me above, it just seems qbittorrent, for all its bells and whistles and features, has WAY WAY WAY too many bugs filed. All I really need is a stable download manager that sits in the background and downloads what I tell it to.

 

PS: No, its not my hardware, I've memtest the crap out of it in the last 2 months, its an otherwise stable Xeon box with ECC ram running a few VM's.

 

Going to try binhex/delugevpn :)

I assume that you are downloading to the cache drive?

 

What format is it? BTRFS? Might be a good idea to run a scrub of it if so. A corrupted file is generally going to be a drive issue of some sort.

 

Also I found out the hard way that unraid does not monitor btrfs cache pools for errors like it does the main array. You have to do this manually. I use a script run every hour now to check for any errors.

Link to comment
7 hours ago, TexasUnraid said:

I assume that you are downloading to the cache drive?

 

What format is it? BTRFS? Might be a good idea to run a scrub of it if so. A corrupted file is generally going to be a drive issue of some sort.

 

Also I found out the hard way that unraid does not monitor btrfs cache pools for errors like it does the main array. You have to do this manually. I use a script run every hour now to check for any errors.

I am downloading to a share with an SSD cache enabled formatted with BTRFS. Just ran a scrub, no errors.  The cache is a brand new (literally 2 weeks old) seagate barracuda 500 GB.  I'm pretty sure this is a qbittorrent corruption, as what good is a cache/unraid setup if it just corrupts files arbitrarily (barring actual physical hardware problems)?

 

Would hardlink versus copy have anything to do with the corruption?  I'm not sure if I should have it set one way or the other.   Currently the Share where the files write out to is an array (I use high watermark array) where both the donwloads and final media locations are, with the SSD cache as a buffer.

/data/media/tvshows

/data/media/movies

/data/media/torrents

 

So far unraid reports no errors on the array or cache, and my setup is pretty well stressed tested before i converted it to unraid 2 weeks ago (ran 24 hours of prime95) and another 12+ hours of memtest86.

 

The CPU/mobo/ram are used,  the disks are a mix of old and new (but all check out with zero errors)   and I got an LSI controller (sata mode) for the spinning rust, with the cache connected directly to the motherboard bridge because I read that cache on an LSI SAS controller isn't an optimal setup.

 

I might go back to qbittorrent (with binhex suggestion to force check option at the end of every DL) because turning off uTP on deluge seems to be a big pain in the butt with a plugin (ltConfig) that isn't updated for a long time, and apparently isn't working exactly 100% (boolean check boxes not working) and I got the same problem someone else reported, even if I manually change it in the config file, it still isn't getting me above the ~1.5MB/sec wall.   At least on qbittorrent I was pushing up to 20MB/sec (160Mbit)

 

 

 

BTW, Thank you binhex for tracking down the bug on the additional trackers!!! You are awesome!

Edited by mooky
Link to comment

If it is a cache enabled share, then that means mover will move files off the SSD to the disk you tell it to at night.

 

It is conceivable that if this move happened during the download this could cause corruption of some kind. Mover is not really designed for that use case far as I know, more designed for files copied during the day and then moved at night type of thing but not an expert.

 

I have had random corruption issues like you in the past where several torrents were said to be complete but after a recheck they were actually not complete. In every case there was other funky stuff going on at the same time that was either caused by a hardware hiccup or just general strangeness.

 

In my case a fresh reboot and cleaning up all the torrents I could led to everything working fine.

 

I would setup a BTRFS error watching script though, just in case. I got this from Jonnie IIRC

 

#!/bin/bash
#description=This script will check the cache pool for any errors and send a notification if any are found. You must clear any errors after fixing the issue using the command: btrfs dev stats -z /mnt/cache
#backgroundOnly=
#arrayStarted=true
#noParity=
#argumentDescription=
#argumentDefault=

echo
echo Starting check of cache
if mountpoint -q /mnt/cache; then
btrfs dev stats -c /mnt/cache
if [[ $? -ne 0 ]]; then /usr/local/emhttp/webGui/scripts/notify -i warning -s "ERRORS found on cache pool: /mnt/cache"; fi
fi

 

Link to comment
6 minutes ago, TexasUnraid said:

I have had random corruption issues like you in the past where several torrents were said to be complete but after a recheck they were actually not complete. In every case there was other funky stuff going on at the same time that was either caused by a hardware hiccup or just general strangeness.

 

In my case a fresh reboot and cleaning up all the torrents I could led to everything working fine.

That doesn't instill confidence. I come from a comp sci background, those sorts of things just shouldn't be, cache should be seamless and without errors barring major hardware malfunction, or an inopportune power failure without a UPS.  A random 1 in a billion file corruption because of an OS/kernel problem, sure. But it should be RARE, like willy wonka golden ticket rare.

Link to comment

Well, I should be clear, I don't use mover, so that was not the issue for me and it did it even on my old server with windows. So it is not an unraid issue I am pretty sure in my case.

 

It was only like 3 times to me, once was due to my download drive filling up, the second could of also been caused by the drive filling up but so much data was being shuffled around I could not know for sure.

 

Another time 2 torrents were downloading to the same folder for some reason and caused some corruption.

 

I think there might of been 1 more time when the server was just generally having issues that day but can't remember.

 

In all of these cases there were outside issues that caused the corruption though.

Link to comment
3 minutes ago, mooky said:

You don't use mover, or you don't use a cache at all?  Just curious.

I don't use mover, My downloads either download directly to the cache and I manually do what I want with them or Sonarr/radarr etc handle the moving all automatically.

 

For my use case mover just would not help me much and would cause a lot of excess writes to the cache (for file transfers, not downloads). It is perfectly fine and I very well might find a use for it down the road but because I have reconstruct write enabled and my drives stay spinning 24/7 at the moment, they are already enough to max out a gigabit connection without the need for the cache.

 

Generally any of my 10GB P2P transfers are talking directly to a cache only share.

 

I am also a believer in minimizing drive usage whenever possible, be it SSD or spinning rust. I have hand many drives last over 10 years and keep on ticking with this strategy, so might as well stick with it.

Link to comment
Just now, SignedOne said:

@binhex Is there any easy way to downgrade qBittorrent to < v4.2.5 inside the container without breaking things? Versions >= v4.2.5 permabroke importing stuff in sonarr/radarr due to QBt changing things. E.g. this sonarr PR will fix it: https://github.com/Sonarr/Sonarr/pull/3346

yep its simplicity itself!, follow Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/unraid.md

  • Haha 1
Link to comment
On 10/13/2020 at 3:49 PM, binhex said:

ahh ive spotted the issue!, you cannot use custom bridge with a fixed ip in the same range as your lan network, so you could do a fixed ip in another range that is different to the lan network, or simply use the default 'bridge'.

Hey binhex, I think I am having a similar issue to dnLL. I am using PIA and I have switched to the new network already as part of my troubleshooting.

 

For the longest time I always had all my dockers on one independent VLAN so qbittorrentvpn has IP 10.15.1.57 and my unRAID host would be on another VLAN with IP 10.15.0.30. Since a few days ago I can no longer access qbittorrent from my other containers on the 10.15.1.0 VLAN (sonarr, radarr, reverse proxy). I can access it from my other subnets without issue. Like dnLL if I turn off the VPN I can access qbittorrent without issue from the 10.15.1.0 VLAN. 

 

Looking at pfsense I am getting an entry like this (10.15.1.50 is my reverse proxy):

image.thumb.png.b564ac8af567b41552febd649ffcb1de.png

Google-fu tells me that TCP:SA is related to asymmetric routing but trying to configure the floating rules does nothing to help. This kinda makes sense because my reverse proxy would be accessing qbittorrent over the "switch" within unraid/docker but for some reason qbittorrent is sending its reply to the default gateway. Does not explain why this issue only started since the 4.3.0 update but even if I downgrade it does not work again. I even tried a whole new container and still not working.

 

I'm stumped. Is this the same/similar issue as dnLL?

Link to comment

Really not sure what happened but I noticed this morning that my unRaid server had started an unscheduled parity check so I started checking other things. It looks like something has also happened with this docker. the docker wouldn't start and after a little checking i discovered that the oven file was blank. I corrected that by replacing it. Now the docker is running but there are no torrents. I know I can re-add the torrents using the watch folder but if I do this all the seed times will be lost. Is there some way to get everything back using the backups?

 

brunnhilde-diagnostics-20201025-1205.zip

Link to comment
1 hour ago, TexasUnraid said:

Anyone else noticed significantly slower speeds with pia the last few weeks? Seeing speeds about 1/3 what they used to be across a few different dockers using PIA/OVPN

Make sure you're on the new network.

 

They don't have many servers left on the old network, dozens (depending on where you are connecting), compared to hundreds for the next gen servers

 

remote us-chicago.privacy.network 1197  (new - 729 servers)

remote us-chicago.privateinternetaccess.com 1197 (old - 12 servers)

 

https://www.privateinternetaccess.com/pages/network/

Link to comment
Just now, mooky said:

Make sure you're on the new network.

 

They don't have many servers left on the old network, dozens (depending on where you are connecting), compared to hundreds for the next gen servers

 

remote us-chicago.privacy.network 1197  (new - 729 servers)

remote us-chicago.privateinternetaccess.com 1197 (old - 12 servers)

 

https://www.privateinternetaccess.com/pages/network/

Yep, switched to the new network and have tried going back to the old network as well but all servers I have tried seem to be much slower then before.

Link to comment
2 minutes ago, TexasUnraid said:

Yep, switched to the new network and have tried going back to the old network as well but all servers I have tried seem to be much slower then before.

Try another server? Maybe your ISP is having routing issues.   Yesterday I was getting 25MB/sec from my PIA connection of choice.

Edited by mooky
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.