search

qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
28k stars 3.95k forks source link

False trackers "Updating" status for many hours since qbt start, despite announce actually finished? #21234

Open slrslr opened 2 months ago

slrslr commented 2 months ago

qBittorrent & operating system versions

qbt 4.6.5 Linux AppImage Qt: 6.6.3 Libtorrent: 2.0.11.0 Boost: 1.85.0 OpenSSL: 1.1.1w zlib: 1.2.11

What is the problem?

State of the qbt:

3800 resumed torrents 900 out of that containing private trackers most of the torrents containing one or several http trackers (unlike http trackers, udp trackers always update quickly)

max. concurrent http announces: 300 (i had to limit it, since tracker hosting provider was not OK single IP hitting it more than 300 times) max. connections 500 max. per torrent 6 max. sending per torrent 10 tracker HTTPS certs. verification disabled in adv. settings (has been also enabled with same result) stop tracker timeout 8s. in adv. settings qbittorrent.conf important lines

Problem:

It takes 24-48 hours for a http kind of trackers (does not matter if public or private) in torrents to stop showing Updating status. Though even before that happens, when i check the tracker website, I can see myself as a active peer under most of the torrents peers list (priv. tracker shows VIP users the list of peers and their last activity/announce time), with last update time to be in last minutes (despite qbt shows Updating, no message from a tracker and N/A peer counts).

That suggests that qbt announced ok, but failed to just display correct http tracker status (and peer counts?). Please note that some http trackers are having Updating status, yet the message column shows "Torrent is not authorized ...", "timed out", "Host not found". So the failure/delay in displaying is only in the status column of the http tracker and possibly also peer counts. Same issue is in a WebUI apparently.

An example: After 2 hours of runtime, I have found only single torrent out of 70 examined, which contained a working http tracker, it was non-private one. Rest torrents contained http trackers in (likely fake) Updating state.

One user thinks that announcing on too many network interfaces may also play role: https://github.com/qbittorrent/qBittorrent/issues/14453#issuecomment-1036563746

List of similar issues: Private trackers either "Not working" or "Updating #16500 Torrent / Tracker status not resetting #16492 Stuck / Stalled at 0%. Tracker: Updating #14453 I2P Tracker always stuck at Updating 4.6.0RC2 #19625

Steps to reproduce

No response

Additional context

No response

Log(s) & preferences file(s)

No response

thalieht commented 2 months ago

Can you try 5.0.0rc1?

stalkerok commented 2 months ago

Additional context

It would be nice if you could add screenshots to better understand the problem.

slrslr commented 2 months ago

I have no compatible system for v5.x Regarding screenshots, I think that you can use the one in leading post of the above mentioned issue #19625 , it shows how trackers list shows when updating.

stalkerok commented 2 months ago

These are i2p trackers, nothing to do with this issue.

ghost commented 2 months ago

In my situation I also experience the serialization of many operations inside the App.

The App does one thing and puts many other things on hold for the previous thing to finish. Or so it seems I am not sure what App-internal resource is being overburdened.

For example the Move operations pauses the tracker announce operations.

Another example the UI does not show what the underlying torrenting operations are actually doing, the UI is frozen on some occasions - Percentage bars being out of place and not showing correct percentage, Seeders page empty.

So to me it looks like thread issue where the operations human wants, are being held up by thread thats doing something.

slrslr commented 4 weeks ago

Under 5.0.0 lt2 AppImage the issue remains.

Priv. tracker message during long term tracker status "Updating" is "skipping tracker announce (unreachable)".

When I click drop down arrow before the tracker announce URL, it shown my local v4 and v6 IP where v6 is Updating (and "skipping ... unreachable") and v4 is Working. BT protocol 1 both.

Later though I have found that v6 shown Unreachable and v4 Working. In such case, the common status for both is "Working". Idea on improvement: Would it make sense if developers change the behavior and show common Working status even if v6 is updating but v4 working?

The priv. tracker in question (public UDP ones works) does not support IPv6 per the https://domsignal.com/ipv6-test and https://ready.chair6.net/?url= After checking my own v6 connectivity using https://test-ipv6.com/ it passed 10/10.

This is possibly not a v6 only problem, because I have spotted that then both v4 and v6 interfaces shown a priv. tracker Updating status in all torrents that I have checked - again stuck with no change. Upon stopping the torrent and resuming, the priv. tracker often (if not always) does not announce (shows: Not contacted yet) and upon forcing it to announce it does nothing (no status change and the tracker website does not show any recent announcing by me). All this happens 1-6 hour after launch without any significant operations from my side. Torrent count/settings is in my leading post here.

slrslr commented 2 weeks ago

I have got rid of this issue (temporarily) by removing no longer working trackers. Thanks to a lack of more advanced tracker management (https://github.com/qbittorrent/qBittorrent/issues/8457), it took me a few hours (https://forum.qbittorrent.org/viewtopic.php?t=11774). Now the http / private trackers updates instantly or in a few seconds. It may help temporarily - until one increases torrent/trackers count again. I do not consider this issue as solved.