starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Gracefully closing a torrent without deleting #8175

New issue

Closed

opened 2026-02-21 19:24:20 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-21 19:24:20 -05:00

Owner

Originally created by @etopylight on GitHub (Dec 14, 2018).

qBittorrent version and Operating System

qBittorrent v4.1.4 (64-bit); Windows 10 Build 17763

What is the problem

From observation, hitting the pause button on a torrent does not seem to send a stop event request to the tracker. Consequently, the tracker will not clear the peer from the peer list until timeout is reached.

This might cause a problem in private trackers whenever I want to switch seeding from a machine to another. Considering that I am only allowed to seed & leech from one client at a time, if the tracker does not receive a stop event request from the first client, the other client cannot seed until the tracker reaches timeout on the first client.

What is the expected behavior

The client should have a mechanism to send a stop event request of a torrent to the tracker.

Extra info(if any)

By the way, in rtorrent, it is possible to gracefully close a torrent with the (^k) shortcut. The same for uTorrent as well by simply pressing the stop button.

Originally created by @etopylight on GitHub (Dec 14, 2018). ### qBittorrent version and Operating System qBittorrent v4.1.4 (64-bit); Windows 10 Build 17763 ### What is the problem From observation, hitting the pause button on a torrent does not seem to send a stop event request to the tracker. Consequently, the tracker will not clear the peer from the peer list until timeout is reached. This might cause a problem in private trackers whenever I want to switch seeding from a machine to another. Considering that I am only allowed to seed & leech from one client at a time, if the tracker does not receive a stop event request from the first client, the other client cannot seed until the tracker reaches timeout on the first client. ### What is the expected behavior The client should have a mechanism to send a stop event request of a torrent to the tracker. ### Extra info(if any) By the way, in rtorrent, it is possible to gracefully close a torrent with the (^k) shortcut. The same for uTorrent as well by simply pressing the stop button.

deekerman

2026-02-21 19:24:20 -05:00

closed this issue
added the
Core
label

deekerman commented

2026-02-21 19:24:28 -05:00

Author

Owner

@Supralateral commented on GitHub (Dec 16, 2018):

Pausing a torrent definitely used to/should send a stop event to the tracker.
BTW, the most popular private tracker software (Ocelot/Gazelle) does not immediately remove a client from the peer list even if it sends (and the tracker receives) the stop event.

@Supralateral commented on GitHub (Dec 16, 2018): Pausing a torrent definitely used to/should send a stop event to the tracker. BTW, the most popular private tracker software (Ocelot/Gazelle) does **not** immediately remove a client from the peer list even if it sends (and the tracker receives) the stop event.

deekerman commented

2026-02-21 19:24:30 -05:00

Author

Owner

@etopylight commented on GitHub (Dec 16, 2018):

Yup, just confirmed that qbittorrent does actually send a stop event request to the tracker, so I guess this part should be fine.

GET /announce.php?event=stopped&peer_id=-qB4140-PEc~RPaaVY~9 [truncated]

After a bit more investigation, the tracker that I'm still having problem with the peer stats not being updated properly has 2 IPv4 + 2 IPv6 addresses binded to its hostname. For example:

$ host test.tracker
test.tracker has address 192.168.10.1
test.tracker has address 192.168.20.1
test.tracker has IPv6 address 2001::1111:a001
test.tracker has IPv6 address 2001::1111:b001

If I configure [Options] -> [Advanced] -> [Optional IP Address to bind to] to a specific address, the problem disappears. However, if instead select all addresses the problem reappears again.

Interestingly enough, after firing up Wireshark to do some more debugging, I discovered that qbittorrent actually sends out 2 identical requests simultaneously to the 2 addresses at the same time whenever I click resume or pause on a torrent. Maybe this somehow confuses the tracker? By binding my client to a single address enables it to send a single request to either address at a time and the tracker behaves normally again.

At first I thought it might have something to do with the dual IPv4+IPv6 binding, but switching to rtorrent on the same machine runs without any problem too.

@etopylight commented on GitHub (Dec 16, 2018): Yup, just confirmed that qbittorrent does actually send a stop event request to the tracker, so I guess this part should be fine. `GET /announce.php?event=stopped&peer_id=-qB4140-PEc~RPaaVY~9 [truncated]` After a bit more investigation, the tracker that I'm still having problem with the peer stats not being updated properly has 2 IPv4 + 2 IPv6 addresses binded to its hostname. For example: ``` $ host test.tracker test.tracker has address 192.168.10.1 test.tracker has address 192.168.20.1 test.tracker has IPv6 address 2001::1111:a001 test.tracker has IPv6 address 2001::1111:b001 ``` If I configure [Options] -> [Advanced] -> [Optional IP Address to bind to] to **a specific address**, the problem disappears. However, if instead select **all addresses** the problem reappears again. ![capture](https://user-images.githubusercontent.com/7758516/50066919-5c633200-01f9-11e9-88e1-5007bfe23ece.png) Interestingly enough, after firing up Wireshark to do some more debugging, I discovered that qbittorrent actually sends out 2 identical requests simultaneously to the 2 addresses at the same time whenever I click resume or pause on a torrent. Maybe this somehow confuses the tracker? By binding my client to a single address enables it to send a single request to either address at a time and the tracker behaves normally again. At first I thought it might have something to do with the dual IPv4+IPv6 binding, but switching to rtorrent on the same machine runs without any problem too.

deekerman commented

2026-02-21 19:24:30 -05:00

Author

Owner

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

Thanks for the report.

qBittorrent does send the stop announce when torrents are paused. It also now has a Stop tracker timeout setting. Increasing the value will increase the chance that the stop announce actually makes it to the tracker, in cases where the connection to the tracker is on the slow side.

Improper support for multi-homed hosts as mentioned in https://github.com/qbittorrent/qBittorrent/issues/10008#issuecomment-447722557 is a tracker bug.

@FranciscoPombal commented on GitHub (Jul 20, 2020): Thanks for the report. qBittorrent does send the stop announce when torrents are paused. It also now has a `Stop tracker timeout` setting. Increasing the value will increase the chance that the stop announce actually makes it to the tracker, in cases where the connection to the tracker is on the slow side. Improper support for multi-homed hosts as mentioned in https://github.com/qbittorrent/qBittorrent/issues/10008#issuecomment-447722557 is a tracker bug.

deekerman referenced this issue

2026-02-21 21:06:02 -05:00

I know .unwanted folder was meant to be gone, but what's new behaviour supposed to be? #11013

deekerman referenced this issue

2026-02-21 21:06:02 -05:00

I know .unwanted folder was meant to be gone, but what's new behaviour supposed to be? #11013