starred/qBittorrent

Fork 0

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

Stop button? #4054

New issue

Closed

opened 2026-02-21 17:06:32 -05:00 by deekerman · 6 comments

deekerman commented

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

Owner

Originally created by @PresidioSF on GitHub (Mar 16, 2016).

Can we get a button to actually "Stop" torrents rather than simply Pause them?

Reason:
In other clients, when a torrent is stopped, the client disregards the torrent in future. This means that the actual files can be removed as the client never seems to pay attention to them again - unless the torrent is restarted (on purpose or accidentally) and the files are not there, then the client would show an error.

However, in qBitTorrent, because the torrent has only been paused, if the client is restarted, those that were removed now show up as "! Missing Files", as qBitT must be performing a check for the files existing again when restarted.

Stop button would be really helpful here to correct this behavior.

Seeing a sea of red "! Missing Files" always adds some concern when looking at the client each time.

Originally created by @PresidioSF on GitHub (Mar 16, 2016). Can we get a button to actually "**Stop**" torrents rather than simply Pause them? Reason: In other clients, when a torrent is stopped, the client disregards the torrent in future. This means that the actual files can be removed as the client never seems to pay attention to them again - unless the torrent is restarted (on purpose or accidentally) and the files are not there, then the client would show an error. However, in qBitTorrent, because the torrent has only been paused, if the client is restarted, those that were removed now show up as "! Missing Files", as qBitT must be performing a check for the files existing again when restarted. Stop button would be really helpful here to correct this behavior. Seeing a sea of red "! Missing Files" always adds some concern when looking at the client each time.

deekerman

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

closed this issue
added the
Not an issue
label

deekerman commented

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

Author

Owner

@chrishirst commented on GitHub (Mar 16, 2016):

Pause IS stop

@chrishirst commented on GitHub (Mar 16, 2016): [Pause IS stop](https://qbforums.shiki.hu/index.php/topic,2666.msg16127.html#msg16127)

deekerman commented

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

Author

Owner

@PresidioSF commented on GitHub (Mar 16, 2016):

If pause is stop, then why the need for the "! Missing Files" regarding those files which have been stopped (paused as you say), when really they could just be marked as Completed instead?

As discussed in example above, this is how Stop would function in other clients - items at 100% and stopped are then marked as Completed.

@PresidioSF commented on GitHub (Mar 16, 2016): If pause is stop, then why the need for the "! Missing Files" regarding those files which have been stopped (paused as you say), when really they could just be marked as Completed instead? As discussed in example above, this is how Stop would function in other clients - items at 100% and stopped are then marked as Completed.

deekerman commented

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

Author

Owner

@sledgehammer999 commented on GitHub (Mar 16, 2016):

It has been discussed again multiple times.
Our pause is like utorrent's stop. It stops all connections to peers and all network activity for that torrent. The only difference is that it still checks for files' presence according to fastresume data upon client start.
I am not going to change that. The use case of "I keep my torrents in the list but I delete the actual files" is bizarre. I don't consider it important enough to recode the queuing logic.

@sledgehammer999 commented on GitHub (Mar 16, 2016): It has been discussed again multiple times. Our pause is like utorrent's stop. It stops all connections to peers and all network activity for that torrent. The only difference is that it still checks for files' presence according to fastresume data upon client start. I am not going to change that. The use case of "I keep my torrents in the list but I delete the actual files" is bizarre. I don't consider it important enough to recode the queuing logic.

deekerman commented

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

Author

Owner

@PresidioSF commented on GitHub (Mar 16, 2016):

LOL @ this:

The use case of "I keep my torrents in the list but I delete the actual files" is bizarre.

Don't see what is bizarre about it, there are those of us who like to stop the torrent and keep the files in another location/on another disk. It means that if you throw a torrent in the queue that you already downloaded , another torrent client recognises that you already completed it. qBitTorrent is instead showing the torrent once existed but files are missing > not very helpful, very confusing!

Being discussed multiple times and that it keeps on coming up is kind of a clue that users must really want it.

But whatever! :)

@PresidioSF commented on GitHub (Mar 16, 2016): LOL @ this: > The use case of "I keep my torrents in the list but I delete the actual files" is bizarre. Don't see what is bizarre about it, there are those of us who like to stop the torrent and keep the files in another location/on another disk. It means that if you throw a torrent in the queue that you already downloaded , another torrent client recognises that you already completed it. qBitTorrent is instead showing the torrent once existed but files are missing > not very helpful, very confusing! Being discussed multiple times and that it keeps on coming up is kind of a clue that users must really want it. But whatever! :)

deekerman commented

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

Author

Owner

@sledgehammer999 commented on GitHub (Mar 16, 2016):

There are 2 cases: Users that intentionally moved the files and users that forgot to mount to the drive/partition or somehow lost progress. The 2nd category benefits greatly from that status.

Random thought for the 1st group of people is: Have them mark which torrents to not monitor. Behind the scenes we still monitor those torrents and their files but instead of "missing files" they get a "unmonitored" status.

@sledgehammer999 commented on GitHub (Mar 16, 2016): There are 2 cases: Users that intentionally moved the files and users that forgot to mount to the drive/partition or somehow lost progress. The 2nd category benefits greatly from that status. Random thought for the 1st group of people is: Have them mark which torrents to not monitor. Behind the scenes we still monitor those torrents and their files but instead of "missing files" they get a "unmonitored" status.

deekerman commented

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

Author

Owner

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

uTorrent's "pause" is fundamentally flawed and bad for the whole BitTorrent ecosystem.

See the first response in https://forum.utorrent.com/topic/90647-whats-the-difference-between-stop-and-pause-in-utorrent/ and the 11th reply in https://forum.utorrent.com/topic/37335-pause-torrents-or-exit-utorrent-any-difference/.

It keeps the peer connections alive doing nothing at all, thus wasting system resources doing nothing at all. The purported benefit of this is "faster resume times" - but I don't think the difference vs. using stop (if it's even significant at all) justifies wasting other's system resources and connection limits. This is very anti-social behavior for a P2P network application.
It does not immediately send the "stop" announce to the tracker, and apparently keeps sending regular announces for some time (unclear if this latter, more serious misbehavior is still present in the later versions, though). Again, this is bad for the whole swarm - peers contacting the tracker will receive useless uTorrent peers in their peer lists that have the torrents paused and will thus not send or receive any pieces. Not to mention this would be considered "cheating" in a private tracker.

qBittorrent prevents all this bullshit by having the correct system: only 2 buttons, "start" and "paused", where "paused" means the same as uTorrent's "stop", i.e., peer connections are actually closed and the stop event is announced to the tracker.

Problems/suggestions/considerations about torrent error state transitions depending on missing/moved files are orthogonal to this problem - they can be solved/changed without having an additional """paused""" state like in uTorrent.

@FranciscoPombal commented on GitHub (Jul 20, 2020): uTorrent's "pause" is fundamentally flawed and bad for the whole BitTorrent ecosystem. See the first response in https://forum.utorrent.com/topic/90647-whats-the-difference-between-stop-and-pause-in-utorrent/ and the 11th reply in https://forum.utorrent.com/topic/37335-pause-torrents-or-exit-utorrent-any-difference/. - It keeps the peer connections alive doing nothing at all, thus wasting system resources doing nothing at all. The purported benefit of this is "faster resume times" - but I don't think the difference vs. using stop (if it's even significant at all) justifies wasting other's system resources and connection limits. This is very anti-social behavior for a P2P network application. - It does not immediately send the "stop" announce to the tracker, and apparently keeps sending regular announces for some time (unclear if this latter, more serious misbehavior is still present in the later versions, though). Again, this is bad for the whole swarm - peers contacting the tracker will receive useless uTorrent peers in their peer lists that have the torrents paused and will thus not send or receive any pieces. Not to mention this would be considered "cheating" in a private tracker. qBittorrent prevents all this bullshit by having the correct system: only 2 buttons, "start" and "paused", where "paused" means the same as uTorrent's "stop", i.e., peer connections are actually **closed** and the stop event is announced to the tracker. Problems/suggestions/considerations about torrent error state transitions depending on missing/moved files are orthogonal to this problem - they can be solved/changed without having an additional """paused""" state like in uTorrent.