mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
New Bug - v4.2.1 - All Trackers Listed as Error #9485
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#9485
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ryannathans on GitHub (Dec 17, 2019).
Please provide the following information
qBittorrent version and Operating System
v4.2.1, Windows 10 1909
What is the problem
Since upgrading, on startup all torrents seem to be listed correctly but a small amount of time (I assume announcing to all trackers) all torrents/trackers appear as "Error" on the left category bar despite most torrents not having any errors on the trackers.
What is the expected behavior
As in previous versions, only torrents with tracker errors should appear listed under tracker "Errors"
Steps to reproduce
Start the program with existing torrents (that have trackers)
Extra info(if any)
Possibly related to having DHT, LSD and PEX disabled globally. (pls implement #7743 )
@ArcticGems commented on GitHub (Dec 17, 2019):
Does qBittorrent's log show any errors? (if it does, post it)
@ryannathans commented on GitHub (Dec 17, 2019):
No, the latest messages are binding to IP addresses
@ryannathans commented on GitHub (Dec 18, 2019):
Maybe the trackers had errors but they show as working in this version?
I left the PC running for 2 hours and now only some show as "Error" (some of the errored ones have "not working" trackers, but some still show all "working")
@nokti commented on GitHub (Dec 18, 2019):
Same here, I just upgraded to 4.2.1 and now all my torrents but one are showing tracker error. 90% of my torrents are private, with DHT disabled and only one tracker annonce per torrent which says working.
@ryannathans commented on GitHub (Dec 18, 2019):
Another few hours and they're all back to error again. No idea why but it's definitely some new bug in 4.2.1. Same situation as @nokti with 90% private trackers, no DHT/PEX/LSD and 1-3 trackers per torrent that say working (and none that say not working)
@p43b1 commented on GitHub (Dec 18, 2019):
Confirm. Windows 10 4.2.1 all tackers not working
@Desiato66 commented on GitHub (Dec 18, 2019):
Came here looking for an answer to this problem so I have registered to confirm this bug. I have two private trackers, one seeding 41 torrents and 95% are working but in the Error section. The other tracker with 312 seeds with roughly half Not Working and half Working. Force reannouncing them removes them from the Error section but within an hour they are all back in the Error section again.
@ghost commented on GitHub (Dec 18, 2019):
The trackers are working fine but qBit is moving them to error section.
@Desiato66 commented on GitHub (Dec 19, 2019):
Yeah, I should have said the larger tracker is having issues so the Not Working is not the fault of qBittorrent.
@beeeeswax commented on GitHub (Dec 19, 2019):
Same problem here, torrents bounce in and out of the 'Error' section of the Trackers node. None of them show anything in the 'Message' column and their status is always 'Working'. Tracker site shows all torrents seeding also so it appears to be a cosmetic issue. No errors in the qBit execution log.
qBit 4.2.1
Windows Server 2019 (fully patched)
@Lash78 commented on GitHub (Dec 20, 2019):
This bug is related to ipv6. Workaround: change bind ip in advanced options to "All IPv4 addresses".
@Desiato66 commented on GitHub (Dec 22, 2019):
@Lash78 The All IPv4 addresses setting has fixed the issue with one tracker (which is struggling to maintain connection for its torrents so they keeping appearing in the Error section as Not Working but after a reboot today, I have 6 working torrents from another tracker in the Error section so not completely fixed.
@ArcticGems commented on GitHub (Dec 22, 2019):
@sledgehammer999 @Chocobo1
Did this bug get introduced by PR = https://github.com/qbittorrent/qBittorrent/pull/11592 ?
@sledgehammer999 commented on GitHub (Dec 22, 2019):
Can you guys try this test build? It PR #11733 on top of 4.2.1.
Remember to re-enable all interfaces/all addresses.
Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11691.7z
(run it from any folder or overwrite original files)
@Lash78 commented on GitHub (Dec 22, 2019):
Almost good... but when you start the program, it shows the errors first and then starts to decreasing to zero.
@sledgehammer999 commented on GitHub (Dec 22, 2019):
I think that's inevitable and probably ok. The first endpoints to "report back" are probably the dummy local IPv6 addresses which will report a failure. But as soon as the IPv4 addresses contacts the tracker (which is a slower operation than locally fail) the errors will be zeroed out per torrent per tracker.
@ghost commented on GitHub (Dec 23, 2019):
It's working as expected.
@beep054 commented on GitHub (Feb 2, 2020):
@influx3k commented on GitHub (Apr 24, 2020):
Still having this issue with 4.2.4. All torrents errored but one. All the ones that are errored say "Not Working" but no tracker message. Did see this error in the Execution Log:
4/24/20 9:34 PM - Failed to listen on IP: 192.168.1.11, port: UDP/32500. Reason: Address already in use
@FranciscoPombal commented on GitHub (Apr 24, 2020):
There is a program running already bound to that endpoint. Terminate that program or configure it to use another address/port, and restart qBittorrent.