[Support] binhex - qBittorrentVPN

[Florris]

7 hours ago, wgstarks said:

I’m not seeing anything obvious. I wonder if it could be a server issue???

Protonvpn works on my PC or my Phone no problem, using the openvpn credentials the other guy talked about didn't work either for me.

[wgstarks]

5 minutes ago, Florris said:

Protonvpn works on my PC or my Phone no problem, using the openvpn credentials the other guy talked about didn't work either for me.

The OpenVPN credentials are the right ones to use but your logs would show “auth failed” if it was your credentials.

[PaulieW]

I'm experiencing a major memory leak using qBit, posted about it on the qBit github here: https://github.com/qbittorrent/qBittorrent/issues/20117#issuecomment-1998091075

 

Does any of you have the same issue? Can it be fixed at the container level or does it need to be addressed in qBit?

Is there an option to roll back to a previous version 4.5.x in the binhex container? (No idea if that will fix the issue though but may be worth a shot).

[wgstarks]

24 minutes ago, PaulieW said:

Is there an option to roll back to a previous version 4.5.x in the binhex container? (No idea if that will fix the issue though but may be worth a shot).

You can roll back to any version using the dockerhub tag numbers in the repository field of the docker configuration. The format is <repository name>:<tag number>. The repository name should already be entered so just type a colon and then a tag number and hit apply. Looks like the last 4.5 tag was 4.5.5-1-04.

[nickydd9]

Would there ever be consideration for packaging an alternative WebUI into this container? Right now I have Vuetorrent installed by grabbing the latest build from Github, extracting it into my appdata folder in Unraid and then mapping it to binhex-qbittorrentvpn, however I can't figure out any easy way to keep Vuetorrent up to date without manually updating it. 

 

If Vuetorrent was packaged in this would be a more seamless upgrade experience through Community Applications just having to update the VPN container. Hotio's qbit container has it packaged in.

[PaulieW]

24 minutes ago, wgstarks said:

You can roll back to any version using the dockerhub tag numbers in the repository field of the docker configuration. The format is <repository name>:<tag number>. The repository name should already be entered so just type a colon and then a tag number and hit apply. Looks like the last 4.5 tag was 4.5.5-1-04.

Thanks, I rolled back to 4.5.2 as that is apparently still a popular version being used. But to no avail: I started with 27GB free memory, and after launching qBit 4.5.2 this went down to 18GB within 20 minutes or so. And still dropping...

 

Surely if everyone had this issue it would be a much more critical issue being dealt with. How can it be that others don't experience this but I do?

[Kev600]

Hey Guys,

Has anybody got this working with FastestVPN?

I have a lifetime license and would rather not have to purchase another VPN product - PIA is used in all the tutorials, but I'd be interested to hear what and how you use others?

 

Many Thanks
Kev

[wgstarks]

23 minutes ago, PaulieW said:

Thanks, I rolled back to 4.5.2 as that is apparently still a popular version being used. But to no avail: I started with 27GB free memory, and after launching qBit 4.5.2 this went down to 18GB within 20 minutes or so. And still dropping...

 

Surely if everyone had this issue it would be a much more critical issue being dealt with. How can it be that others don't experience this but I do?

Are you sure it’s not a path mapping problem? It’s possible you could be creating directories in ram and writing files to them. You can post your docker run command if you’re not sure. Be sure to redact users/passwords.

Edited March 14 by wgstarks

[PaulieW]

13 minutes ago, wgstarks said:

Are you sure it’s not a path mapping problem? It’s possible you could be creating directories in ram and writing files to them. You can post your docker run command if you’re not sure. Be sure to redact users/passwords.

 

Alright here goes, see attached. Anything useful in there? Seems all pretty generic to me.

 

docker run qBit.txt

[wgstarks]

9 minutes ago, PaulieW said:

 

Alright here goes, see attached. Anything useful in there? Seems all pretty generic to me.

 

docker run qBit.txt 1.21 kB · 2 downloads

The only thing I see out of the ordinary is that you have defined VPN ports. That’s not normally necessary.

[PaulieW]

18 hours ago, wgstarks said:

The only thing I see out of the ordinary is that you have defined VPN ports. That’s not normally necessary.

Correct I added 4 VPN Output ports;

59142: The forwarded port provided by my VPN provider. Indeed this probably is not needed.

8081: The listening port of a 2nd binhex-qBit docker, so that its connection goes through the main qBit 8080 docker.

2468: Cross-seed

2469: Cross-seed of 2nd binhex-qBit docker

 

But none of these could be having anything to do with memory piling up I imagine?

 

Edit: Well apparently it had everything to with it lol. As soon as I start the 2nd binhex-qBit container, my available memory starts to drop significantly. 

I'm routing the traffic like this:

As followed by @SpaceInvaderOne's guide: 

https://www.youtube.com/watch?v=znSu_FuKFW0&t=315s

 

But it seems this network routing method doesn't work properly for 2 qBittorrent containers, causing memory leak issues.

 

@binhex are you aware of such memory issues when 2 binhex-qbittorrent containers are routed as described?

Edited March 15 by PaulieW

[binhex]

18 hours ago, PaulieW said:

are you aware of such memory issues when 2 binhex-qbittorrent containers are routed as described?

i have never thought of doing that!!, you won't get a incoming port for the second container and thus your speeds will be low, you know that right?.

 

18 hours ago, PaulieW said:

Correct I added 4 VPN Output ports;

59142: The forwarded port provided by my VPN provider. Indeed this probably is not needed.

seriously, don't do this!, this is not what it's used for, see warning:-
 

Quote

IMPORTANT
Please note 'VPN_INPUT_PORTS' is NOT to define the incoming port for the VPN, this environment variable is used to define port(s) you want to allow in to the VPN network when network binding multiple containers together, configuring this incorrectly with the VPN provider assigned incoming port COULD result in IP leakage, you have been warned!.

 

[s449]

Is there any way to diagnose why qBittorrentVPN is spiking my CPU? It keeps jumping from 1% -> 40% -> 2% -> 30%, etc. As far as my Unraid Processor load shows, it kind of sit around 25-30%. Here's what my "docker stats" shows:

 

This is with 0 active torrents. My CPU is: Intel Xeon E3-1230 v3 @ 3.30GHz (full specs in signature). Using qBittorrent v4.3.9, Unraid 6.12.6, docker is pinned to 2 cores, 4 threads. Using AirVPN as my VPN client, if relevant.

 

I assume the issue is that I have 3126 torrents in my client. I actually had 5000 but just yesterday got them down. But the general higher-than-expected idle CPU load has been an issue for a few months now. I only now figured I should debug it.

 

Nothing seemingly out of the ordinary in my qBittorrentVPN logs:

 

Any insight would be appreciated! Or if it's clearly just my high torrent count, I'll accept that. I'll try to dwindle it down.

Edited March 15 by s449
More info

[PaulieW]

49 minutes ago, binhex said:

i have never thought of doing that!!, you won't get a incoming port for the second container and thus your speeds will be low, you know that right?.

 

seriously, don't do this!, this is not what it's used for, see warning:-
 

 

I did not know both of these things, thanks for pointing that out!

 

More generally speaking then, how do you yourself connect multiple binhex containers to the same VPN IP so that it only counts as 1 device for the VPN provider (and all containers being connectable/port forwarded)?

Edited March 15 by PaulieW

[binhex]

34 minutes ago, PaulieW said:

how do you yourself connect multiple binhex containers to the same VPN IP so that it only counts as 1 device for the VPN provider (and all containers being connectable/port forwarded)?

Yes i do bind multiple containers together via a single vpn container (privoxyvpn), but you will not receive an incoming port for the other containers, so if it's a torrent client (for example) then your only option to assign an incoming port is to create another separate vpn container, most vpn providers permit multiple connections, PIA i think gives you 5.

[PaulieW]

21 minutes ago, binhex said:

Yes i do bind multiple containers together via a single vpn container (privoxyvpn), but you will not receive an incoming port for the other containers, so if it's a torrent client (for example) then your only option to assign an incoming port is to create another separate vpn container, most vpn providers permit multiple connections, PIA i think gives you 5.

Ok that makes sense yes, thank you!

[LondonDragon]

Any ideas why torrents always stalling on Unraid? I have tried various version of clients and they all seem to do the same on the Unraid server, on my Windows PC on the same network using the same VPN service no issues?

Also NZBGet has no issues either.

 

Many thanks

[Rkpaxam]

where do i get the config file for privoxy ?

[wgstarks]

1 hour ago, Rkpaxam said:

where do i get the config file for privoxy ?

appdata/binhex-qbittorrentvpn/privoxy/config

[Rkpaxam]

12 minutes ago, wgstarks said:

appdata/binhex-qbittorrentvpn/privoxy/config

thats empty

[Rkpaxam]

1 minute ago, Rkpaxam said:

thats empty

i mean a deafult template or a completed one?  i know where the storage location is:)

[Rkpaxam]

i downloaded privoxy to my deb laptop and copied the config file and follwed these instructions https://pimylifeup.com/raspberry-pi-proxy-using-privoxy/

 

however when i then try to access my qbit main page it takes me to a privoxy 503

[wgstarks]

That file should have been populated when you enabled privoxy with default settings. Most are commented but I know the listen port is enabled.

[wgstarks]

Just to be sure you understand, this is a proxy server that will allow other dockers to use the vpn connection (Sonarr, Radarr, etc).

[PaulieW]

On 12/27/2023 at 7:36 PM, MaxiWheat said:

 

Ok I think I found what the problem is, or more like how to replicate the issue... I'm not totally sure about the deep root cause, but I have an explaination.

I access each webui by the IP address of my Unraid server with the port (http://10.0.0.xxx:8080 and http://10.0.0.xxx:8081). If I open each webui in different browser tabs at the same time and then interact with them (open settings, change filters, etc.) then the container memory start to grow and grow... as long as I keep the tabs with the webui opened. The problem does not occur if I open a webui alone, close it and open the other. It also happen if I open both with the server name (hostname) instead of the IP address.

 

I think it has something to do with the cookies and/or the authentication for the URL/Hostname used.

 

I was using "Bypass authentication for clients in whitelisted IP subnets" with a single address in it so that my main desktop computer could access the webui without provinding a password. Both containers were set that way and the issue occured. If I uncheck this setting and have to provide a password to access the webgui, if I log into one of the webgui, I get disconnected from the other in the other tab, so the problem does not occur, but I can't use both webgui at the same time in the same browser. This can also be solved by using different hostnames to access each webgui (also need to provide the port).

 

So this is it, if you have more details about this issue or tricks to share, they're welcome

I'm glad you posted this. As you can read from my posts up a bit on this page, I am also having issues with running 2 binhex-qbittorrent containers. I thought initially it was due to the fact that I had routed the traffic of the 2nd one through the 1st. But when I separated them completely, eaching routing the traffic through Bridge and giving them each their own wg0.conf, the problem remained. So the cause had to be something else.

 

When I read your post, it has nothing to do with the traffic routing, but with having both webUI's open in the same browser.

So are you saying that if you open the first one as http://192.168.1.1:8080 and then second one as http://tower.local:8081, then there is no memory issue? As long as the hostname is different?

 

Have you also just tried running one webUI in chrome and the other in firefox for instance?

 

Edit: Can confirm both methods seem to do the trick!

@binhexis this something you would look into?

Edited March 16 by PaulieW