`m_nativeStatus.current_tracker` is only set on client initialization #16220

New issue

Open

opened 2026-02-22 02:54:59 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-22 02:54:59 -05:00

Owner

Originally created by @buroa on GitHub (Oct 13, 2024).

Suggestion

m_nativeStatus.current_tracker is only set on client initialization, which is returned in the qBittorrent API as "tracker": "http://tracker/announce". When libtorrent does the reannounce on the set interval; and the tracker status goes to "Not Working", the current tracker is never removed, or set back to empty/null like it is during the first client initialization.

It would be extremely helpful to clear this field when that tracker announce goes "bad", so we can determine what torrents are in that state, and then we can issue the second API call to grab the tracker statuses and messages.

Use case

When I reannounce torrents on faulty trackers or the trackers remove the infoHash from their database; I'd like to have automaton remove them from my client. I'd like to use less API calls to determine if these torrents need their tracker statuses checked further (another API call), and having that tracker status always update (m_nativeStatus.current_tracker) to what is the real current (nothing or otherwise) will be extremely beneficial.

Extra info/examples/attachments

No response

Originally created by @buroa on GitHub (Oct 13, 2024). ### Suggestion `m_nativeStatus.current_tracker` is only set on client initialization, which is returned in the qBittorrent API as `"tracker": "http://tracker/announce"`. When libtorrent does the reannounce on the set interval; and the tracker status goes to "Not Working", the current tracker is never removed, or set back to empty/null like it is during the first client initialization. It would be extremely helpful to clear this field when that tracker announce goes "bad", so we can determine what torrents are in that state, and then we can issue the second API call to grab the tracker statuses and messages. ### Use case When I reannounce torrents on faulty trackers or the trackers remove the infoHash from their database; I'd like to have automaton remove them from my client. I'd like to use less API calls to determine if these torrents need their tracker statuses checked further (another API call), and having that tracker status always update (`m_nativeStatus.current_tracker`) to what is the real current (nothing or otherwise) will be extremely beneficial. ### Extra info/examples/attachments _No response_

deekerman added the

Feature request

Libtorrent

labels

2026-02-22 02:54:59 -05:00

deekerman commented

2026-02-22 02:55:04 -05:00

Author

Owner

@thalieht commented on GitHub (Oct 13, 2024):

When libtorrent does the reannounce on the set interval; and the tracker status goes to "Not Working", the current tracker is never removed, or set back to empty/nul

Sounds like it's working as intended

// the URL of the last working tracker. If no tracker request has
// been successful yet, it's set to an empty string.
std::string current_tracker;

I'm no expert but it sounds like it is controlled entirely by libtorrent.

@thalieht commented on GitHub (Oct 13, 2024): >When libtorrent does the reannounce on the set interval; and the tracker status goes to "Not Working", the current tracker is never removed, or set back to empty/nul Sounds like it's working as intended >// the URL of the last working tracker. If no tracker request has // been successful yet, it's set to an empty string. std::string current_tracker; I'm no expert but it sounds like it is controlled entirely by libtorrent.

deekerman commented

2026-02-22 02:55:07 -05:00

Author

Owner

@glassez commented on GitHub (Oct 13, 2024):

I'm no expert but it sounds like it is controlled entirely by libtorrent.

👍

@glassez commented on GitHub (Oct 13, 2024): > I'm no expert but it sounds like it is controlled entirely by libtorrent. 👍

deekerman commented

2026-02-22 02:55:07 -05:00

Author

Owner

@xavier2k6 commented on GitHub (May 25, 2025):

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future!
Here are some options available to you:

Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.
Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket.
(new/existing contributors/developers are always welcome)

DO:

Provide constructive feedback.
Display how other projects implemented same/similar etc.

DO NOT:

Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s).
(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)

@xavier2k6 commented on GitHub (May 25, 2025): ## ANNOUNCEMENT! For anybody coming across this **_"Feature Request"_** & would like/love to see a potential implementation in the future! **Here are some options available to you:** 1. Please select/click the 👍 **&/or** ❤ `reactions` in the original/opening post of this ticket. 2. Please feel free _(If you have the "skillset")_ to create a **_"Pull Request"_** implementing what's being requested in this ticket. **_(new/existing contributors/developers are always welcome)_** ____ **DO:** * Provide constructive feedback. * Display how other projects implemented same/similar etc. **DO NOT:** * Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). **(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)**