Torrents are Stalled when added right after published in tracker (racing-related) #9184

New issue

Closed

opened 2026-02-21 20:02:10 -05:00 by deekerman · 21 comments

deekerman commented 2026-02-21 20:02:10 -05:00

Owner

Copy link

Originally created by @BigEd1 on GitHub (Oct 2, 2019).

Please provide the following information

qBittorrent version and Operating System

QB 4.1.8, Linux 16.04 4.19

If on linux, libtorrent-rasterbar and Qt version

Raster=1.1.13, QT=5.5.1

What is the problem

Torrents in most cases go into Stalled mode (no seeds or peers) and in most cases will stay there not doing anything. Some seem to catch and download while others sit there forever. The others that are stalled, if I do a right click and forced announce it will start the download within 3 seconds and complete but I've already lost ratio on these ones. I'm grabbing torrents from a watch folder using autodl-irssi. Using the RSS for some other torrents that seems to work ok without a hitch or Stalled status but these are a lot fewer in numbers. Now most sites will post in IRC the second they hit and may not have seeders on them yet so in the autodl-irssi I've added a delay timer of 5 secs which seems to cut the Stalled ones in half and give the uploader bots time to load and start feeding a torrent.

What is the expected behavior

Anything in Stalled mode should be given high priority and a forced announce every x seconds

Steps to reproduce

(type here)

Extra info(if any)

(type here)

Originally created by @BigEd1 on GitHub (Oct 2, 2019). **Please provide the following information** ### qBittorrent version and Operating System QB 4.1.8, Linux 16.04 4.19 ### If on linux, libtorrent-rasterbar and Qt version Raster=1.1.13, QT=5.5.1 ### What is the problem Torrents in most cases go into Stalled mode (no seeds or peers) and in most cases will stay there not doing anything. Some seem to catch and download while others sit there forever. The others that are stalled, if I do a right click and forced announce it will start the download within 3 seconds and complete but I've already lost ratio on these ones. I'm grabbing torrents from a watch folder using autodl-irssi. Using the RSS for some other torrents that seems to work ok without a hitch or Stalled status but these are a lot fewer in numbers. Now most sites will post in IRC the second they hit and may not have seeders on them yet so in the autodl-irssi I've added a delay timer of 5 secs which seems to cut the Stalled ones in half and give the uploader bots time to load and start feeding a torrent. ### What is the expected behavior Anything in Stalled mode should be given high priority and a forced announce every x seconds ### Steps to reproduce (type here) ### Extra info(if any) (type here)

deekerman 2026-02-21 20:02:10 -05:00

• closed this issue
• added the
  Duplicate
  label

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@Zamana commented on GitHub (Oct 6, 2019):

Hi!

Same here (qBitTorrent-nox 4.1.6 within a FreeBSD jail).

Some torrents in stalled and other in "downloading metadata", and all trackers in "not working" status.

No action make them start to download, although I know that there are a lot of seeders.

Any news on this?

Thanks.
Regards.

@Zamana commented on GitHub (Oct 6, 2019): Hi! Same here (qBitTorrent-nox 4.1.6 within a FreeBSD jail). Some torrents in stalled and other in "downloading metadata", and all trackers in "not working" status. No action make them start to download, although I know that there are a lot of seeders. Any news on this? Thanks. Regards.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Oct 6, 2019):

Zamana,
sounds like you may have a different problem altogether. Mine will load as stalled and stay there for 20-30 minutes before catching and downloading. While stalled they show no seeders/leechers or tracker information. But once they start they are all valid. If I right click and do a forced announced they will start within 3 secs and download fine.

You may want to dig further into why the trackers are showing "not working" like in proper ports, settings allowed per site and they don't have any blocks on your client version.

@BigEd1 commented on GitHub (Oct 6, 2019): Zamana, sounds like you may have a different problem altogether. Mine will load as stalled and stay there for 20-30 minutes before catching and downloading. While stalled they show no seeders/leechers or tracker information. But once they start they are all valid. If I right click and do a forced announced they will start within 3 secs and download fine. You may want to dig further into why the trackers are showing "not working" like in proper ports, settings allowed per site and they don't have any blocks on your client version.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Oct 17, 2019):

Update, Loaded the 4.2.0alpha and still does the same thing and just a much. Been following the process and see that once a site posts the torrent and your autodl grab happens if the torrent hasn't been registered and seeding on site yet it will fail and be listed as stalled. 30 minutes later it will do a re-announce and catch. And by this time you already lost the jump and ratio for that torrent. The Stalled torrent has to be watched better by QB and additional announces/checks ever 2-3 seconds until it works. Most major sites work this way, can't use QB working like this.

@BigEd1 commented on GitHub (Oct 17, 2019): Update, Loaded the 4.2.0alpha and still does the same thing and just a much. Been following the process and see that once a site posts the torrent and your autodl grab happens if the torrent hasn't been registered and seeding on site yet it will fail and be listed as stalled. 30 minutes later it will do a re-announce and catch. And by this time you already lost the jump and ratio for that torrent. The Stalled torrent has to be watched better by QB and additional announces/checks ever 2-3 seconds until it works. Most major sites work this way, can't use QB working like this.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Nov 21, 2019):

Update #2, Still working with the nightly builds and still doing the same. AutoDL the link, it loads into qbittorrent and shows stalled with out a try. It still sits until the next announce (30 min) and downloads. If I'm watching them and see the stalled torrent, I right click and do a force re-announce and all is fine. Plenty of disk space still (1tb+), no other errors. This need to be addressed some how with a preselected and settable option to handle a auto re-announce when this error is seen.

@BigEd1 commented on GitHub (Nov 21, 2019): Update #2, Still working with the nightly builds and still doing the same. AutoDL the link, it loads into qbittorrent and shows stalled with out a try. It still sits until the next announce (30 min) and downloads. If I'm watching them and see the stalled torrent, I right click and do a force re-announce and all is fine. Plenty of disk space still (1tb+), no other errors. This need to be addressed some how with a preselected and settable option to handle a auto re-announce when this error is seen.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@RandomInhabitant commented on GitHub (Dec 12, 2019):

I am seeing the same issue as @Zamana with Bittorrent 4.2.0. Attempt to start a torrent, it appears stalled with 0 (0) Seeds/Peers and won't start, which makes sense if it can't find any working Trackers. I saw the same issue with earlier 4.1.x Bittorrent clients, but there were enough other bugs which now seem to be mostly cured in 4.2.0 that this tracker issue was previously buried, but is now visible.

4.2.0 is having problems with trackers. Sometimes I can get it limping along by going to https://torrenttrackerss.com/torrent-tracker-list/ and adding 82 new trackers, but this doesn't always work either. Like @BigEd1 I previously tried Forced Announce with very limited success. More investigation lead me to notice all the Trackers were in a "Not Working" state. This Tracker "Not Working" is consistent whenever the issue @BigEd1 raised is observed. i.e. On my system it appears to be the same issue.

@RandomInhabitant commented on GitHub (Dec 12, 2019):  I am seeing the same issue as @Zamana with Bittorrent 4.2.0. Attempt to start a torrent, it appears stalled with 0 (0) Seeds/Peers and won't start, which makes sense if it can't find any working Trackers. I saw the same issue with earlier 4.1.x Bittorrent clients, but there were enough other bugs which now seem to be mostly cured in 4.2.0 that this tracker issue was previously buried, but is now visible. 4.2.0 is having problems with trackers. Sometimes I can get it limping along by going to https://torrenttrackerss.com/torrent-tracker-list/ and adding 82 new trackers, but this doesn't always work either. Like @BigEd1 I previously tried Forced Announce with very limited success. More investigation lead me to notice all the Trackers were in a "Not Working" state. This Tracker "Not Working" is consistent whenever the issue @BigEd1 raised is observed. i.e. On my system it appears to be the same issue.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@RandomInhabitant commented on GitHub (Dec 16, 2019):

More data. I see multiple uploads happening, so I went to look at the tracker page and here is what I see (almost all trackers in "Not Working" state):




This one shows:

What I see is occasionally trackers appear to work, but for the most part they don't. I'm not sure why they don't work. A large number of Not-working trackers seems like a good clue about where to look for code opportunities. I doubt there are this many dead trackers on active/recent torrents.

Also the one with a large number of "Not contacted yet" is troubling. If a torrent tracker is in the list, why wouldn't it be contacted? I don't have any connection limits enabled.

@RandomInhabitant commented on GitHub (Dec 16, 2019): More data. I see multiple uploads happening, so I went to look at the tracker page and here is what I see (almost all trackers in "Not Working" state):     This one shows:   What I see is occasionally trackers appear to work, but for the most part they don't. I'm not sure why they don't work. A large number of Not-working trackers seems like a good clue about where to look for code opportunities. I doubt there are this many dead trackers on active/recent torrents. Also the one with a large number of "Not contacted yet" is troubling. If a torrent tracker is in the list, why wouldn't it be contacted? I don't have any connection limits enabled.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Dec 16, 2019):

Not sure where your getting your torrents from but they look like they may be from open/free sites which the DHT/Pex/LSD being on indicate. Private sites will always have these turned off/not allowed. Being on open sites not all trackers will work if they don't actually have that torrent your after (not working) or it being blocked for another reason. Not contacted yet usually means it isn't needed yet as you already have a working tracker established already.

My problem is, an I'm on private tracker only sites, when my AutoDL grabs a new torrent being published via a IRC channel and tries to autoload it into QB I'll get the errors of Invalid torrent, unregged torrent and auto stalls the whole thing. Because it is being grabbed from the the IRC client before it actually hits and registers onsite as valid. Because it Stalls it won't pickup again until 30 minutes later after the next announce or I manually to the re-announce again sooner. Didn't have this problem in rtorrent as it handled it correctly with an additional announce shortly after loading and getting the stalled status and No.. nothing has changed on the sites I'm at either.

@BigEd1 commented on GitHub (Dec 16, 2019): Not sure where your getting your torrents from but they look like they may be from open/free sites which the DHT/Pex/LSD being on indicate. Private sites will always have these turned off/not allowed. Being on open sites not all trackers will work if they don't actually have that torrent your after (not working) or it being blocked for another reason. Not contacted yet usually means it isn't needed yet as you already have a working tracker established already. My problem is, an I'm on private tracker only sites, when my AutoDL grabs a new torrent being published via a IRC channel and tries to autoload it into QB I'll get the errors of Invalid torrent, unregged torrent and auto stalls the whole thing. Because it is being grabbed from the the IRC client before it actually hits and registers onsite as valid. Because it Stalls it won't pickup again until 30 minutes later after the next announce or I manually to the re-announce again sooner. Didn't have this problem in rtorrent as it handled it correctly with an additional announce shortly after loading and getting the stalled status and No.. nothing has changed on the sites I'm at either.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@RandomInhabitant commented on GitHub (Dec 17, 2019):

You're mostly right. I had to load uTorrent to identify which trackers weren't really working. Here is an example which qBittorrent displayed "Downloading metadata" for months restarting qBittorrent almost daily to end the "hung" state. Pointing uTorrent and qBittorrent to the same files/trackers uTorrent is able to download in a few minutes while qBittorrent can't. I can provide more examples, but they look very similar to this one. Both are configured to use the same proxy, and every effort was made to configure both identically. This still looks like a qBittorrent tracker handling issue to me.

uTorrent

qBittorrent

To be clear, I'd rather be running qBittorrent which is why I'm reporting these issues, with your help to get reporting in a usable form and right.

@RandomInhabitant commented on GitHub (Dec 17, 2019): You're mostly right. I had to load uTorrent to identify which trackers weren't _really_ working. Here is an example which qBittorrent displayed "Downloading metadata" for months restarting qBittorrent almost daily to end the "hung" state. Pointing uTorrent and qBittorrent to the same files/trackers uTorrent is able to download in a few minutes while qBittorrent can't. I can provide more examples, but they look very similar to this one. Both are configured to use the same proxy, and every effort was made to configure both identically. This still looks like a qBittorrent tracker handling issue to me. **uTorrent**   **qBittorrent**   To be clear, I'd rather be running qBittorrent which is why I'm reporting these issues, with your help to get reporting in a usable form and right.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@FranciscoPombal commented on GitHub (Dec 17, 2019):

@BigEd1

I'm grabbing torrents from a watch folder using autodl-irssi.

You are facing a common problem that currently makes qbittorrent unsuitable for this kind of stuff.
When you grab a torrent so quickly, it is possible that the tracker hasn't even registered it when qbittorrent starts it. Thus, the initial announce will fail, and qbittorrent only reannounces in 30 minutes (which is a sane libtorrent default for "normal usage"), regardless of the success of the previous announce.

The reannounce frequency is configurable in qbittorrent, but you DO NOT want to set it too high in general, otherwise qbittorrent will spam all trackers with announces all the time. What you actually want, is for qBittorrent to only spam reannounces if the first announce failed within the first few seconds/minutes of the torrent being added. If this option were available, you would have no problems with your setup.

This whole thing has already been discussed in much detail here: https://github.com/qbittorrent/qBittorrent/issues/11419, and the main libtorrent dev is already aware of the problem.

@FranciscoPombal commented on GitHub (Dec 17, 2019): @BigEd1 > I'm grabbing torrents from a watch folder using autodl-irssi. You are facing a common problem that currently makes qbittorrent unsuitable for this kind of stuff. When you grab a torrent so quickly, it is possible that the tracker hasn't even registered it when qbittorrent starts it. Thus, the initial announce will fail, and qbittorrent only reannounces in 30 minutes (which is a sane `libtorrent` default for "normal usage"), regardless of the success of the previous announce. The reannounce frequency is configurable in qbittorrent, but you DO NOT want to set it too high in general, otherwise qbittorrent will spam all trackers with announces all the time. What you actually want, is for qBittorrent to only spam reannounces if the first announce failed within the first few seconds/minutes of the torrent being added. If this option were available, you would have no problems with your setup. This whole thing has already been discussed in much detail here: https://github.com/qbittorrent/qBittorrent/issues/11419, and the main `libtorrent` dev is already aware of the problem.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@Seeker2 commented on GitHub (Dec 19, 2019):

@RandomInhabitant
I noticed in your last message here that you stated:

Both are configured to use the same proxy, and every effort was made to configure both identically. This still looks like a qBittorrent tracker handling issue to me.

In my personal testing of both qBitTorrent and uTorrent, that qBitTorrent had UDP packet handling issues that uTorrent doesn't seem to have. This might carry over to proxies and tracker handling as well. I did not run any qBitTorrent or uTorrent tests with proxies. (...unless you cound Teredo IPv6 stuff years ago as proxy tests.)
Many proxies won't work with UDP packets at all and other proxies will only handle UDP packets under specific and exacting conditions. So qBitTorrent may have proxy UDP packet handling issues that disguises itself as tracker handling issues -- as almost all the trackers shown in the example pictures seem to be udp trackers.

@Seeker2 commented on GitHub (Dec 19, 2019): @RandomInhabitant I noticed in your last message here that you stated: > Both are configured to use the same proxy, and every effort was made to configure both identically. This still looks like a qBittorrent tracker handling issue to me. In my personal testing of both qBitTorrent and uTorrent, that qBitTorrent had UDP packet handling issues that uTorrent doesn't seem to have. This might carry over to proxies and tracker handling as well. I did not run any qBitTorrent or uTorrent tests with proxies. (...unless you cound Teredo IPv6 stuff years ago as proxy tests.) Many proxies won't work with UDP packets at all and other proxies will only handle UDP packets under specific and exacting conditions. So qBitTorrent may have proxy UDP packet handling issues that disguises itself as tracker handling issues -- as almost all the trackers shown in the example pictures seem to be udp trackers.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@RandomInhabitant commented on GitHub (Dec 22, 2019):

@Seeker2 Interesting comment about UDP. Both qBittorrent and uTorrent use the same VPN proxy through the same account, both using SOCK5. uTorrent is able to find UDP trackers through the VPN proxy, and a quick check of the VPN provider forums suggests UDP is -not- blocked. uTorrent behavior would seem to support this claim.

I tried to do some testing by turning off the VPN proxy operating torrent without VPN. Trackers seemed to be found a little faster while VPN is off, including qBittorrent. I really don't like operating this way so I turned the VPN proxy back on, restarted the programs, and uploads/trackers in both programs resumed. The thought occurred to me that UDP Tracker information may be cached, but I'm not sure how to test this as UDP Tracker information could be cached in both the Application and OS and persistent across restarts.

I found a site which tracks "Tracker Performance" https://newtrackon.com/ . The trackers used by my torrents are coming back with high availability, and they are heavily UDP in nature.

Once qBittorrent finally finds a tracker, things seem to progress well and quickly, better than uTorrent from my subjective point of view. qBittorrent can take quite some time to start a new torrent, like half an hour or much more while showing all trackers as "Not working". qBittorrent finds http trackers quickly, which supports your claim of UDP not working well, if at all (UDP does work rarely/sometimes, even through the proxy).

More information, but I'm still stumped. I'll have to rely on the torrent experts here to figure out what's really going on.

@RandomInhabitant commented on GitHub (Dec 22, 2019): @Seeker2 Interesting comment about UDP. Both qBittorrent and uTorrent use the same VPN proxy through the same account, both using SOCK5. uTorrent is able to find UDP trackers through the VPN proxy, and a quick check of the VPN provider forums suggests UDP is -not- blocked. uTorrent behavior would seem to support this claim. I tried to do some testing by turning off the VPN proxy operating torrent without VPN. Trackers seemed to be found a little faster while VPN is off, including qBittorrent. I really don't like operating this way so I turned the VPN proxy back on, restarted the programs, and uploads/trackers in both programs resumed. The thought occurred to me that UDP Tracker information may be cached, but I'm not sure how to test this as UDP Tracker information could be cached in both the Application and OS and persistent across restarts. I found a site which tracks "Tracker Performance" https://newtrackon.com/ . The trackers used by my torrents are coming back with high availability, and they are heavily UDP in nature. Once qBittorrent finally finds a tracker, things seem to progress well and quickly, better than uTorrent from my subjective point of view. qBittorrent can take quite some time to start a new torrent, like half an hour or much more while showing all trackers as "Not working". qBittorrent finds http trackers quickly, which supports your claim of UDP not working well, if at all (UDP does work rarely/sometimes, even through the proxy). More information, but I'm still stumped. I'll have to rely on the torrent experts here to figure out what's really going on.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Dec 22, 2019):

Just to throw this in on my main issue. I am not using UDP nor any VPN. I've not had this problem with other client programs either and the sites I grab off of have not had any changes in a very long time thus leaving the issue with QBittorrent and seeing a Stalled torrent on loading it and not checking again for 30 minutes on the next announce where it kicks in.

@BigEd1 commented on GitHub (Dec 22, 2019): Just to throw this in on my main issue. I am not using UDP nor any VPN. I've not had this problem with other client programs either and the sites I grab off of have not had any changes in a very long time thus leaving the issue with QBittorrent and seeing a Stalled torrent on loading it and not checking again for 30 minutes on the next announce where it kicks in.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@ArcticGems commented on GitHub (Dec 22, 2019):

@RandomInhabitant @Seeker2

sledgehammer999 has created a collective issue about proxy & UDP problems = https://github.com/qbittorrent/qBittorrent/issues/11735

@ArcticGems commented on GitHub (Dec 22, 2019): @RandomInhabitant @Seeker2 sledgehammer999 has created a collective issue about proxy & UDP problems = https://github.com/qbittorrent/qBittorrent/issues/11735

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@Seeker2 commented on GitHub (Dec 23, 2019):

I have not used a proxy, even for testing purposes...unless you consider Teredo (IPv4 to IPv6 gateway) a proxy.

My earlier point was qBitTorrent does not handle UDP-based uTP traffic correctly, so it might not handle other UDP-based traffic correctly either.
So sledge's collective issue #11735 is not a good place for me to post UDP/uTP problems I've found that are not proxy related.

@Seeker2 commented on GitHub (Dec 23, 2019): I have not used a proxy, even for testing purposes...unless you consider Teredo (IPv4 to IPv6 gateway) a proxy. My earlier point was qBitTorrent does not handle UDP-based uTP traffic correctly, so it might not handle other UDP-based traffic correctly either. So sledge's collective issue #11735 is not a good place for me to post UDP/uTP problems I've found that are not proxy related.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@BigEd1 commented on GitHub (Jan 19, 2020):

Well , It took a bit to do but was able to remove and re-install rtorrent. My problem of stalled torrents is now gone. Should my AutoDL grab before it is fully ready to download it keeps attempting and usually grabs it right away without the 30 minute delay in QB. Again, I was not using any VPN, UDP just straight out connections to private sites. Talking with a lot of people in my group and have found they dumped QB for same reason. They were losing ratio on torrents which is never good. Really needs to get answered.

@BigEd1 commented on GitHub (Jan 19, 2020): Well , It took a bit to do but was able to remove and re-install rtorrent. My problem of stalled torrents is now gone. Should my AutoDL grab before it is fully ready to download it keeps attempting and usually grabs it right away without the 30 minute delay in QB. Again, I was not using any VPN, UDP just straight out connections to private sites. Talking with a lot of people in my group and have found they dumped QB for same reason. They were losing ratio on torrents which is never good. Really needs to get answered.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@Seeker2 commented on GitHub (Jan 20, 2020):

Very early in the torrent life cycle, the torrent may be registered on a website (where you first downloaded it) or even on an RSS feed but not yet registered on a tracker.
qBitTorrent might get a tracker fail message and not retry the tracker again for a full cooldown cycle -- usually 30 or 60 minutes -- while other more aggressive BitTorrent apps will retry as fast as every 15-60 seconds.

@Seeker2 commented on GitHub (Jan 20, 2020): Very early in the torrent life cycle, the torrent may be registered on a website (where you first downloaded it) or even on an RSS feed but not yet registered on a tracker. qBitTorrent might get a tracker fail message and not retry the tracker again for a full cooldown cycle -- usually 30 or 60 minutes -- while other more aggressive BitTorrent apps will retry as fast as every 15-60 seconds.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@FranciscoPombal commented on GitHub (Jan 20, 2020):

@BigEd1 @Seeker2
As I've stated before in the previous comment: https://github.com/qbittorrent/qBittorrent/issues/11320#issuecomment-566696168, this issue has to do with qBittorrent's announce interval. It is really a duplicate of https://github.com/qbittorrent/qBittorrent/issues/11419.

@RandomInhabitant @ArcticGems for proxy/udp issues discussions post in the other relevant linked threads.

@thalieht close as duplicate please.

@FranciscoPombal commented on GitHub (Jan 20, 2020): @BigEd1 @Seeker2 As I've stated before in the previous comment: https://github.com/qbittorrent/qBittorrent/issues/11320#issuecomment-566696168, this issue has to do with qBittorrent's announce interval. It is really a duplicate of https://github.com/qbittorrent/qBittorrent/issues/11419. @RandomInhabitant @ArcticGems for proxy/udp issues discussions post in the other relevant linked threads. @thalieht close as duplicate please.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@thalieht commented on GitHub (Jan 20, 2020):

Thanks @FranciscoPombal but i don't think i can close any issue as duplicate of #11419... totally random title and it's asking many things in one issue. Of course i only read the original post.

@thalieht commented on GitHub (Jan 20, 2020): Thanks @FranciscoPombal but i don't think i can close any issue as duplicate of #11419... totally random title and it's asking many things in one issue. Of course i only read the original post.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@FranciscoPombal commented on GitHub (Jan 20, 2020):

@thalieht

Thanks @FranciscoPombal but i don't think i can close any issue as duplicate of #11419... totally random title and it's asking many things in one issue. Of course i only read the original post.

My point was that the main topic of this issue, i.e. everything relating to "qbittorrent's one-size-fits-all announce interval is causing some fresh torrents to stall when added" was/is already being discussed over there (in the comments after the OP).

But I see your point about the title, it's the content that's duplicated really. Your call whether you want to close this as a duplicate or not.

@FranciscoPombal commented on GitHub (Jan 20, 2020): @thalieht > Thanks @FranciscoPombal but i don't think i can close any issue as duplicate of #11419... totally random title and it's asking many things in one issue. Of course i only read the original post. My point was that the main topic of this issue, i.e. everything relating to "qbittorrent's one-size-fits-all announce interval is causing some fresh torrents to stall when added" was/is already being discussed over there (in the comments after the OP). But I see your point about the title, it's the content that's duplicated really. Your call whether you want to close this as a duplicate or not.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@TGD149 commented on GitHub (Jan 28, 2020):

I also have the same issue with random torrents. Added as stalled (usually from RSS feeds) and if i force reannounce they work right away. otherwise they have to wait the 30 minutes to refresh automatically and start.

@TGD149 commented on GitHub (Jan 28, 2020): I also have the same issue with random torrents. Added as stalled (usually from RSS feeds) and if i force reannounce they work right away. otherwise they have to wait the 30 minutes to refresh automatically and start.

deekerman commented 2026-02-21 20:02:13 -05:00

Author

Owner

Copy link

@FranciscoPombal commented on GitHub (Apr 26, 2020):

Closing as duplicate of https://github.com/qbittorrent/qBittorrent/issues/11419, as the title has been adjusted.

@FranciscoPombal commented on GitHub (Apr 26, 2020): Closing as duplicate of https://github.com/qbittorrent/qBittorrent/issues/11419, as the title has been adjusted.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

v5_2_x

v5_1_x

debian

v5_0_x

v4_6_x

v4_5_x

v4_4_x

v4_3_x

v4_2_x

v4_1_x

v4_0_x

v3_3_x

v3_2_x

v3_1_x

v3_0_x

search_encoding_windows

v2_9_x

release-5.1.4

release-5.1.3

release-5.1.2

release-5.1.1

release-5.1.0

release-5.0.5

release-5.0.4

release-5.1.0rc1

release-5.1.0beta1

release-5.0.3

release-5.0.2

release-5.0.1

release-5.0.0

release-4.6.7

release-5.0.0rc1

release-4.6.6

release-4.6.5

release-4.6.4

release-5.0.0beta1

release-4.6.3

release-4.6.2

release-4.6.1

release-4.6.0

release-4.6.0rc2

release-4.5.5

release-4.6.0rc1

release-4.6.0beta1

release-4.5.4

release-4.6.0alpha1

release-4.5.3

release-4.5.2

release-4.5.1

release-4.5.0

release-4.5.0beta1

release-4.4.5

release-4.4.4

release-4.4.3.1

release-4.4.3

release-4.4.2

release-4.4.1

release-4.4.0

release-4.3.9

release-4.4.0rc1

release-4.3.8

release-4.4.0beta3

release-4.3.7

release-4.4.0beta2

release-4.4.0beta1

release-4.3.6

release-4.3.5

release-4.3.4.1

release-4.3.4

release-4.3.3

release-4.3.2

release-4.3.1

release-4.3.0.1

release-4.3.0

release-4.2.5

release-4.2.4

release-4.2.3

release-4.2.2

release-4.2.1

release-4.2.0

release-4.1.9.1

release-4.1.9

release-4.1.8

release-4.1.7

release-4.1.6

release-4.1.5

release-4.1.4

release-4.1.3

release-4.1.2

release-4.1.1

release-4.1.0

release-4.0.4

release-4.0.3

release-4.0.2

release-4.0.1

release-4.0.0

release-3.3.16

release-3.3.15

release-3.3.14

release-3.3.13

release-3.3.12

release-3.3.11

release-3.3.10

release-3.3.9

release-3.3.8

release-3.3.7

release-3.3.6

release-3.3.5

release-3.3.4

release-3.3.3

release-3.3.2

release-3.3.1

release-3.3.0

release-3.2.5

release-3.2.4

release-3.2.3

release-3.2.2

release-3.2.1

release-3.2.0

release-3.1.12

release-3.1.11

release-3.1.10

release-3.1.9.2

release-3.1.9.1

release-3.1.9

release-3.1.8

release-3.1.7

release-3.1.6

release-3.1.5

release-3.1.4

release-3.1.3

release-3.1.2

release-3.1.1

release-3.1.0

release-3.0.11

release-3.0.10

release-3.0.9

release-3.0.8

release-3.0.7

release-3.0.6

release-3.0.5

release-3.0.4

release-3.0.3

release-3.0.2

release-3.0.1

release-3.0.0

release-2.9.11

release-2.9.10

release-2.9.9

release-2.9.8

release-2.9.7

release-2.9.6

release-2.9.5

release-2.9.4

release-2.9.3

release-2.9.0

release-2.8.5

release-2.8.4

release-2.8.3

release-2.8.2

release-2.7.1

release-2.7.0

release-2.6.9

release-2.6.8

release-2.6.7

release-2.6.5

release-2.6.4

release-2.6.3

release-2.6.2

release-2.6.1

release-2.6.0

release-2.5.5

release-2.5.4

release-2.5.3

release-2.5.2

release-2.5.0

release-2.5.0rc1

release-2.4.11

release-2.5.0beta6

release-2.5.0beta5

release-2.5.0beta3

release-2.4.10

release-2.4.8

release-2.5.0beta2

release-2.5.0beta1

release-2.4.6

release-2.4.4

release-2.4.2

release-2.4.0

release-2.4.0rc3

release-2.4.0rc1

release-2.4.0beta3

release-2.4.0beta1

release-2.3.1

release-2.3.0

release-2.3.0rc6

release-2.2.11

release-2.3.0rc5

release-2.2.10

release-2.2.9

release-2.2.8

release-2.2.6

release-2.2.5

release-2.2.3

release-2.2.2

release-2.2.1

release-2.2.0

release-2.1.6

release-2.1.4

release-2.1.2

release-2.1.1

release-2.1.0

release-2.0.7

release-2.0.6

release-2.0.5

release-2.0.3

release-2.0.2

release-2.0.0

release-2.0.0rc6

release-2.0.0rc2

release-1.5.6

release-1.5.4

release-1.5.3

release-1.5.0

release-1.5.0rc5

release-1.5.0rc4

release-1.5.0rc3

release-1.5.0rc1

release-1.5.0beta4

release-1.5.0beta3

release-1.5.0beta2

release-1.5.0beta1

release-1.4.1

release-1.4.0

release-1.4.0rc2

release-1.4.0rc1

release-1.3.5

release-1.4.0beta3

release-1.3.4

release-1.3.3

release-1.3.1

release-1.3.0

release-1.2.1

release-1.2.0rc1

release-1.2.0beta6

release-1.1.4

release-1.2.0beta5

release-1.1.3

release-1.2.0beta3

release-1.1.2

release-1.2.0beta2

release-1.1.1

release-1.2.0beta1

release-1.1.0

release-1.1.0rc2

release-1.1.0rc1

release-1.1.0beta3

release-1.1.0beta2

release-1.0.0

release-1.0.0rc11

release-1.0.0rc10

release-1.0.0rc9

release-1.0.0rc8

release-1.0.0rc7

release-1.0.0rc6

release-1.0.0rc5

release-1.0.0rc4

release-1.0.0rc3

release-0.9.3

release-0.9.2

Labels

Clear labels   

Accessibility

  

AppImage

  

Bounty

  

Build system

  

CI

  

Can't reproduce

  

Code cleanup

  

Confirmed bug

  

Confirmed bug

  

Core

  

Crash

  

Data loss

  

Discussion

  

Docker

  

Documentation

  

Duplicate

  

Feature

  

Feature request

  

Feature request

  

Feature request

  

Filters

  

Flatpak

  

GUI

  

Has workaround

  

I2P

  

Invalid

  

Libtorrent

  

Look and feel

  

Meta

  

NSIS

  

Network

  

Not an issue

  

OS: *BSD

  

OS: Linux

  

OS: Windows

  

OS: macOS

  

PPA

  

Performance

  

Project management

  

Proxy/VPN

  

Qt bugs

  

Qt6 compat

  

RSS

  

Search engine

  

Security

  

Temp folder

  

Themes

  

Translations

  

Triggers

  

Waiting diagnosis

  

Waiting info

  

Waiting upstream

  

Waiting web implementation

  

Watched folders

  

WebAPI

  

WebUI

  

autoCloseOldIssue

No labels

Accessibility

AppImage

Bounty

Build system

CI

Can't reproduce

Code cleanup

Confirmed bug

Confirmed bug

Core

Crash

Data loss

Discussion

Docker

Documentation

Duplicate

Feature

Feature request

Feature request

Feature request

Filters

Flatpak

GUI

Has workaround

I2P

Invalid

Libtorrent

Look and feel

Meta

NSIS

Network

Not an issue

OS: *BSD

OS: Linux

OS: Windows

OS: macOS

PPA

Performance

Project management

Proxy/VPN

Qt bugs

Qt6 compat

RSS

Search engine

Security

Temp folder

Themes

Translations

Triggers

Waiting diagnosis

Waiting info

Waiting upstream

Waiting web implementation

Watched folders

WebAPI

WebUI

autoCloseOldIssue

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/qBittorrent#9184

No description provided.