qBittorrent official forums

Hi there.

I've been having constant issues with qBittorrent 3.2.0 stalling (DHT: 0) and newly added magnet links enter the "Downloading metadata" non stop.

While changing my router port forwarding options and leaving a torrent seeding for a little more than 12 hours, I returned home and was happy to notice that DHT wasn't 0 and the torrent seeded a bit. If I'm right, I believe that I've solved the stalled issue in my case. You might want to try this method if you're having a similar problem, even if you're not using Linux.

Take a look at the screenshot below. The Internal IP Address must be your LAN ip address and it must also be static (no DHCP). The Internal Start and End Ports must be the same port you have opened in qBittorrent (it'll be the same for TCP and UDP, which also affects DHT if active). Now the most important part (for me), which is the Remote Host Address has to be your socks proxy ip address. If your proxy host allows you to use a domain name, like socks5.proxy.org (which cycles different ip addresses) it will not work in this case. I used 127.0.0.1 (localhost) as an example and you should not use it. Replace it with the socks ip address that you set in qBittorrent. If you leave the Remote Host Address as 0.0.0.0 qBittorrent 3.2.0 will leak your internet ip address, even with Anonymous Mode and Disable connections not supported by proxies on (it leaked for me; it might not leak for you). The External Start and End Ports must be the same as the Internal Start and End Ports. And finally make sure you select both protocols (TCP and UDP). If you need to test your ports, you can visit https://www.grc.com/ (ShieldsUP) or http://www.canyouseeme.org/. If you need help configuring port forwarding for your router, visit http://portforward.com/. Port Triggering is disabled in my case.
Now your router might not have the option to specify the Remote Host Address, in which case you'll have to check if the option is somewhere else, if it is there at all. To clarify what the Remote Host Address means, read section b of http://arris.force.com/consumers/articles/General_FAQs/SBG6580-v358x-Port-Forwarding-Setup/?l=en_US&fs=RelatedArticle.

If you're in doubt about my configuration, check the other screenshots below. You can use them as a reference.



Main qBittorrent window. Notice the Green Status Icon and the number of DHT nodes after a little more than 12 hours. This wasn't happening before.



qBittorrent Libraries.



Relevant Options. I suggest you do not enable Local Peer Discovery. The reason is that qBittorrent will open listening sockets on all present interfaces even if you specify a single Network Interface in the Advanced Options. It might not actually connect (I didn't test it thoroughly) but it is annoying to see all those network interfaces in "$ netstat -tunaepc | grep -i qbittorrent" (run this in a terminal emulator).







So in the end I got a Green Status Icon (it was always yellow before) and DHT nodes doesn't zero anymore, so hopefully no more stalled torrents and magnet links. I still have some more tinkering that I want to do, but the basics are done.

Edit 01: I turned the Router Firewall back on and about 06 hours later I noticed that DHT: 0 nodes. Well, it's off now and when I clicked on the Trackers Button and then back to the General button, qBittorrent started picking up DHT nodes again. I'll keep updating as I can.

Edit 02: Router Firewall is on, but this time I've disabled Socks5, adjusted the Router Firewall accordingly and turned DHT and PeX on (Anonymous Mode is off). After 06 hours DHT hasn't gone to 0, so I'm going to leave qBittorrent in this state for another 12 hours. Perhaps the DHT stalled issue is Socks Proxy related? qBittorrent Status is green with no active downloads or uploads. Waiting to see if it stalls (DHT: 0 nodes) after these next 12 hours.

Edit 03: So far so good. DHT is still fresh after these 12 hours, with Socks Proxy turned off. Next test will be to turn Socks Proxy back on and DHT off. Will check if torrents stall this way or not (when I actually download something).

Edit 04: Not good this time. Socks Proxy is on as is Anonymous Mode. DHT and Pex are off. I disabled the port forwarding from my router because I saw an IP Address that wasn't the Socks Proxy connecting. I compared the IP Address with the peers list of the torrent that I was running and it wasn't there, so I don't know what happened. netstat clearly showed an IP Address establishing a connection, but since it wasn't apparently a peer I'm clueless to what it was. More bad news too. I tried adding a new magnet link and it stalled. Since DHT is off, it seems the Socks Proxy is related to this issue. Only disabling Anonymous Mode this time.

Edit 05: After trying many combinations, there is one option that helps against this issue. It's painted in red in the third screenshot below. Now qBittorrent 3.2.0 still stalls after a while, but when I add a new magnet link and it stalls, I just click on "OK", pause it and then try downloading again. If it doesn't start downloading the first time, pause and start again. On the second time (you might have to try more than twice) it starts downloading here and DHT goes up if it is 0. And before I forget, usually there is one tracker in the magnet link, so I've yet to try using a magnet link with no trackers, but as far as I can remember it did work before. And port forwarding in the router is disabled for the qBittorrent port. If you can, please try enabling the same option (don't forget to restart qBittorrent) I have (marked in red) and report your results.

Tip 01: Turn on "Resolve peer host names" and see if that helps.

Tip 02: If you have seeded torrents that have stalled and DHT is 0, switch between the "General" and the "Trackers" button a few times. Doing so usually makes DHT increase in my case, so you don't have to restart qBittorrent. If the torrent is trackerless, try adding a tracker and see if that helps, but I don't think it's necessary.

Tip 03: If you have a stalled torrent from a freshly added magnet link, restart it a few times and it should begin to download.





"Resolve peer host names" helps in my case. If it helps you, please report.



Edit 06: To show how weird this issue is, this week I went to sleep one night with qBittorrent showing DHT:0, and when I woke up it was around 380. Probably one of the torrents I was seeding did some uploading and triggered DHT to refresh the nodes or something. It's the only possibility I can think of right now.

Edit 07: Upgraded to libtorrent-1.0.6 (from https://github.com/arvidn/libtorrent/releases; you won't find libtorrent-1.0.6 in http://sourceforge.net/projects/libtorrent/ which is why I was still using libtorrent-1.0.5) and qBittorrent-3.2.3. qBittorrent-3.2.2 has "FEATURE: Allow to force reannounce DHT too (Chocobo1)" so perhaps it might help with this stalled issue. I'm currently seeding a few torrents as I write this, so time will tell.

Edit 08: qBittorrent-3.2.3 + libtorrent-1.0.6 still stalls.

Edit 09: qBittorrent-3.2.3 has been running here for a few days now without stalling anymore. I'm not going to say this is fixed, because I have to experiment changing some options in qBittorrent-3.2.3 and see if it stalls then. The secret? Apparently changing my DNS server did it. Even with a http proxy in Firefox my browsing also improved a lot. If anyone else is reading this and has the same issue, try changing to a faster DNS server (check it with "$ ping -c 5 <dns server ip address>"; the "time=" output should be as low as possible; currently I'm getting around 30ms while google's 8.8.8.8 and 8.8.4.4 are around 120ms) and please share the news. For me the DNS servers are stored in "/etc/resolv.conf" like "nameserver 8.8.8.8" if you want to use google's (your distro might be different; max 03 DNS server lines in "/etc/resolv.conf"). I'll update again at another date.

Edit 10: Instead of leaving the details here and risk people missing the fun, I decided to make a reply. More people are ought to see "bumps" anyway.

Compass.

I'm using qbittorrent 3.12 in Windows. I tried 3.2, but noticed the stalled torrents and DHT: 0 nodes like you mentioned. I tried tweaking the router, but ultimately falling back to 3.12 has provided consistent relief. I plan to stay with 3.12, which works great and gives no problems, for a couple of years, maybe forever...

qBittorrent 3.1.10 was also stalling here, so unfortunately in my case changing versions isn't going to help.

In "Edit 05" I have re-enabled "Resolve peer host names" which I was using before beginning this thread. It's the best result I've got so far, although not a fix in itself (qBittorrent 3.2.0 still stalls, but at least restarting the torrent two or three times gets it working).

Compass.

The only setting my router needs is passthrough for the port range used by qbittorrent for dht and tracker. 6800 - 6900 in my case. Passthrough to the specific static IP address of the torrenting computer. I do not use DHCP, but have static IP addresses on my network.

ENABLE "Require encryption" and use a proxy server in order to disguise your torrenting from your ISP. These measures should be sufficient.

"Resolve host names" merely gives the human something to eyeball from curiosity. I disable that as a waste of bandwidth.

Here is my screenshot of qbittorrent 3.12 settings which work great.

ENABLE "Require encryption" and use a proxy server in order to disguise your torrenting from your ISP

Using ports in the 6800 to 6900 isn't going to "disguise" it much.

Hi there. OP here.

[Short Version] Use the fastest DNS Server you can find. If it's slow, qBittorrent is likely to stall at some point, meaning DHT: 0 nodes and you'll stop downloading and seeding automatically.[/Short Version]

[Long Version] I left qBittorrent running for 04 (four) days straight, and not once has it stalled.

Configure your distribution (mine is /etc/resolv.conf; $ man resolv.conf; your case might be different) to use the fastest DNS Server you can find (with the ping command; $ ping -c 5 <dns_server_goes_here>; the shorter the "time=" reply, the better) and you're set!

I don't know if this is a bug in qBittorrent or maybe libtorrent, but if the DNS Server you're using is too slow to reply, qBittorrent/libtorrent apparently times out and does not recover. I also noticed now that the Status Icon is constantly green, even with a SOCKS5 Proxy set. And with no Port Forwarding either.

Due to this being solved, I changed a few options in qBittorrent, like turning off "Resolve Peer Host Names". Before you start changing options in qBittorrent like I did in the posts above, use a fresher DNS Server and leave qBittorrent running a few days. If your issue is the same as mine, it should not stall anymore.[/Long Version]

Added [SOLVED] to the Topic Title. If I was sure it was a bug I'd use [FIXED]. Perhaps someone can look into this? I'm no coder. Sorry.

Compass.

the fastest DNS Server you can find

Or use:

8.8.8.8 & 8.8.4.4 (Google DNS)
and/or
208.67.222.222 & 208.67.220.220 (Open DNS)

instead of your ISP provided DNS

ciaobaby wrote:

the fastest DNS Server you can find

Or use:

8.8.8.8 & 8.8.4.4 (Google DNS)
and/or
208.67.222.222 & 208.67.220.220 (Open DNS)

instead of your ISP provided DNS

In my case google's DNS servers are too slow. OpenDNS isn't better.

$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=131 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=133 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=142 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=132 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=157 ms

$ ping -c 5 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_seq=1 ttl=48 time=139 ms
64 bytes from 8.8.4.4: icmp_seq=2 ttl=48 time=130 ms
64 bytes from 8.8.4.4: icmp_seq=3 ttl=48 time=140 ms
64 bytes from 8.8.4.4: icmp_seq=4 ttl=48 time=131 ms
64 bytes from 8.8.4.4: icmp_seq=5 ttl=48 time=130 ms

$ ping -c 5 208.67.222.222
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=52 time=124 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=52 time=123 ms
64 bytes from 208.67.222.222: icmp_seq=3 ttl=52 time=125 ms
64 bytes from 208.67.222.222: icmp_seq=4 ttl=52 time=125 ms
64 bytes from 208.67.222.222: icmp_seq=5 ttl=52 time=122 ms

$ ping -c 5 208.67.222.220
PING 208.67.222.220 (208.67.222.220) 56(84) bytes of data.
64 bytes from 208.67.222.220: icmp_seq=1 ttl=54 time=124 ms
64 bytes from 208.67.222.220: icmp_seq=2 ttl=54 time=143 ms
64 bytes from 208.67.222.220: icmp_seq=3 ttl=54 time=149 ms
64 bytes from 208.67.222.220: icmp_seq=4 ttl=54 time=121 ms
64 bytes from 208.67.222.220: icmp_seq=5 ttl=54 time=121 ms

$ ping -c 5 x.x.x.x
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x: icmp_seq=1 ttl=53 time=15.1 ms
64 bytes from x.x.x.x: icmp_seq=2 ttl=53 time=26.0 ms
64 bytes from x.x.x.x: icmp_seq=3 ttl=53 time=12.9 ms
64 bytes from x.x.x.x: icmp_seq=4 ttl=53 time=11.6 ms
64 bytes from x.x.x.x: icmp_seq=5 ttl=53 time=13.3 ms

x.x.x.x DNS is closer and faster. No more stalling from qBittorrent!

Compass.

In my case google's DNS servers are too slow

Run your own local caching server in that case, it doesn't need to be authoritative so only needs to be able to fetch zone data from one or more upstream name servers and/or the 13 g-tld root clusters.

You only need a old P4 machine, 512M memory at most,  centOS 6 with BIND 9  or Win 2K server with MS DNS server.

ciaobaby wrote:

In my case google's DNS servers are too slow

Run your own local caching server in that case, it doesn't need to be authoritative so only needs to be able to fetch zone data from one or more upstream name servers and/or the 13 g-tld root clusters.

You only need a old P4 machine, 512M memory at most,  centOS 6 with BIND 9  or Win 2K server with MS DNS server.

It's done.

I've finished configuring /etc/nscd.conf and have left nscd running with google's DNS servers back in /etc/resolv.conf

Will have to wait a while to see how it goes.

Thanks.

Compass.

As a follow up, nscd is working flawlessly here.

I've only had one instance when I noticed that qBittorrent had diminishing DHT nodes, but it didn't stall. I added fresh magnet links at the time, so maybe that forced a DNS request.

Anyway, nscd is a very easy method allowing you to use alternative (and very slow) DNS servers, while greatly optimizing your DNS requests.

Compass.

One little thing I'd like to point out...
If you have a global limit of 60 connections but your half-open limit is set to 30, it might be a bit of a burden on a VPN or proxy despite the low global number.
It also can "tie up" much of the global connections so you never reach >50 connected peers+seeds at once...even if they're available.
I'd even expect the high half-open limit in conjunction with the proxy to cause stalled torrents after 4+ hours of running.
Might even cause an occasional proxy disconnection.

[quote="Switeck"]
One little thing I'd like to point out...
If you have a global limit of 60 connections but your half-open limit is set to 30, it might be a bit of a burden on a VPN or proxy despite the low global number.
It also can "tie up" much of the global connections so you never reach >50 connected peers+seeds at once...even if they're available.
I'd even expect the high half-open limit in conjunction with the proxy to cause stalled torrents after 4+ hours of running.
Might even cause an occasional proxy disconnection.
[/quote]

Is there a recommended ratio between the Global Limit and the Half Open Limit?

I'll do some experimenting here then.

Thanks!

Compass.

Only in the sense that everything has to fit under/into the global connection max.
Try setting half open to only 5-10. Leave global the same.
Starting up qBitTorrent and new torrents may be a tiny bit slower, but efficiency and reliability should go up slightly.

[quote="Switeck"]
Only in the sense that everything has to fit under/into the global connection max.
Try setting half open to only 5-10. Leave global the same.
Starting up qBitTorrent and new torrents may be a tiny bit slower, but efficiency and reliability should go up slightly.
[/quote]

I currently set qBittorent half open connections to 15 (before I saw your post), and for now I think I'll keep it as it is. I might later on reduce it to something between 5 and 10 like you mentioned.

On another note, yesterday qBittorrent completely stalled. Even restarting the client didn't help, and since the DNS servers I'm using were responding to ping requests, I changed the Ip Address of the Socks5 Proxy, and now it's gone back to normal.

That's one thing to remember. If qBittorrent stalls even with fresh DNS Servers, it's worth changing (or pinging first) the Socks5 Proxy Ip Address you're currently using, and see if it replies appropriately or not.

Compass.