Paused Torrents Un-Pause Upon Restart

MAC OS X specific questions, problems.
Post Reply
jonkeys
Newbie
Newbie
Posts: 2
Joined: Thu Oct 10, 2019 2:25 pm

Paused Torrents Un-Pause Upon Restart

Post by jonkeys »

Hi folks,

I think this fits into the "Is the 'pause' button actually a 'stop' button" discussion, as I'll pause the majority of my torrents to manually manage what I'm downloading at any given time, but when I restart qBittorent, some paused torrents un-pause and begin to download, which mean I have to annoyingly pause them again.

How can I keep torrents permanently paused, as in stopped?

Many thanks
ThyTorrenter
Member
Member
Posts: 20
Joined: Mon Jul 07, 2014 11:37 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by ThyTorrenter »

I'm on Windows, but you can't do that. On Github, Stop requests are being denied because "qBittorrent's 'pause' is like uTorrent's stop". This is false, because on uTorrent stopped torrents are NOT resumed with the Resume All function. Only Paused ones are being resumed.

Obviously, this has NOTHING to do with peer connections and the like.

So, the Resume All function in qBittorrent is useless or crippled for me (and others, like you), because I have several stopped/paused torrents on the list I want to keep, but not resume with the Resume All function.

It's perfectly fine if you don't want to implement a Stop function, but why keep telling us it's exactly the same as uTorrent? It is not.
FranciscoPombal
Member
Member
Posts: 54
Joined: Wed Sep 09, 2020 10:34 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by FranciscoPombal »

OP, you are experiencing a bug. There is probably something wrong with the fastresumes of the paused (aka stopped) torrents that keep resuming when you restart the client. This shouldn't happen; paused (aka stopped) torrents should stay paused until the user resumes (aka restarts) them explicitly. That said, I never observed your issue - all the torrents that I pause (aka stop) stay paused (aka stopped) after a restart.
ThyTorrenter wrote: Tue Sep 15, 2020 8:25 am I'm on Windows, but you can't do that. On Github, Stop requests are being denied because "qBittorrent's 'pause' is like uTorrent's stop". This is false, because on uTorrent stopped torrents are NOT resumed with the Resume All function. Only Paused ones are being resumed.

Obviously, this has NOTHING to do with peer connections and the like.

So, the Resume All function in qBittorrent is useless or crippled for me (and others, like you), because I have several stopped/paused torrents on the list I want to keep, but not resume with the Resume All function.

It's perfectly fine if you don't want to implement a Stop function, but why keep telling us it's exactly the same as uTorrent? It is not.
This post is offtopic, as it has nothing to do with the bug that OP is experiencing.

You have absolutely no idea what you are talking about. Go read the source code, if you must, because you are just wrong. This all comes from libtorrent.

In qBittorrent, "Pause", aka "stop", stops all data transfer and tears down all peer connections associated with the torrent. You can even verify this with Wireshark. This is functionally equivalent to uTorrent's stop button.

The fact that uTorrent's "resume all" function does not "resume" torrents that are "stopped" comes from the fact that it distinguishes "stop" from "paused", and thus the opposites of those operations are "restart" and "resume", respectively - so it makes sense that "resume" does not act on stopped torrents, only on paused ones. uTorrent's "resume all" button is NOT functionally equivalent to qBittorrent's "resume all" button, because qBittorrent does not make the disctinction between pause and stopped. Not sure why you would think that "qBit's pause being functionally equivalent to uTorrent's stop" would imply "qBit's resume all being functionally equivalent to utorrent's resume all", given the differences in how they handle these states and the transitions between them.

uTorrent's "pause" stops all data transfer, but doesn't tear down the peer connection. qBittorrent does not implement this deliberately, for the reasons explained in the github comments that you have most likely read already.

If the torrents that you want to keep seeding/downloading are already active, why do you click "resume all"? If you close the client with them resumed, they will resume automatically when you restart the client. If you want to keep torrents around that you don't want to be active, just keep them paused (aka stopped). IMO it seems you just misunderstood the functionality and its intended use, and are are using it wrong due to attempting to force uTorrent's broken workflow when using qBittorrent.
ThyTorrenter
Member
Member
Posts: 20
Joined: Mon Jul 07, 2014 11:37 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by ThyTorrenter »

Ok, sorry for misreading the OP's post.

You also failed to read mine though. I specifically mentioned I'm not questioning anything about peer connections, yet you bring up Wireshark, data transfers etc. claiming yet again "this is functionally equivalent to uTorrent's stop button". But this was never the issue here. Being PARTIALLY equivalent is NOT equivalent. You then go on to downright confirm it:
FranciscoPombal wrote: Sat Sep 19, 2020 11:07 amThe fact that uTorrent's "resume all" function does not "resume" torrents that are "stopped" comes from the fact that it distinguishes "stop" from "paused"... so it makes sense that "resume" does not act on stopped torrents, only on paused ones.
So, you reject everything I said, yet confirm it.
FranciscoPombal wrote: Sat Sep 19, 2020 11:07 amNot sure why you would think that "qBit's pause being functionally equivalent to uTorrent's stop" would imply "qBit's resume all being functionally equivalent to utorrent's resume all"
I wouldn't (the whole point of this request), but tell that to those claiming "qBittorrent's 'pause' is like uTorrent's stop, so forget about adding Stop". The Resume function is directly connected to the Pause function. You Pause something and then you Resume that something alone. Not something else, and that is why uT's way is more intuitive. Again, forget about peer connections. Irrelevant here.
FranciscoPombal wrote: Sat Sep 19, 2020 11:07 amIf the torrents that you want to keep seeding/downloading are already active, why do you click "resume all"?
Because I've pressed "Pause All" first for whatever reason? It is right next to "Resume All", you know. And if you weirdly ask again 'why do you press Pause All', well there are several reasons, mostly bandwidth-related.

To reiterate (yet again). I am not asking the change of the Pause function. I am not questioning it. It will stay exactly as it is. I am NOT talking about peer connections. I'm just asking to make a distinction between Pause and Stopped, to be able to Resume Paused torrents only, not ALL torrents. Resume is connected to Pause. You don't just Resume everything. So, if you ever re-think about this, the "Stop" function would ONLY be related to "Pause All/Resume All" i.e. unaffected by those. Nothing else. Apart from that difference, it would be the same as Pause. The "Stop" term is not loved due to the uT confusion? Use Hibernated, Frozen, Inactive, Isolated, Excluded or whatever.

I'm not "attempting to force uTorrent's broken workflow" but it seems that you are constantly ignoring a missing feature here. It might not matter to you or it might be an unimportant feature, but it is missing.
ThyTorrenter
Member
Member
Posts: 20
Joined: Mon Jul 07, 2014 11:37 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by ThyTorrenter »

Having said the above, I can understand how separate Pause/Stop functions might confuse some users. Don't get me wrong, qB is brilliant. The best. Few real-life examples of "Stopped" torrents the user wouldn't want to start with "Resume All".

1. Huge torrents with disk space implications that are being partially and carefully downloaded and resumed
2. Bandwidth and/or ratio hungry torrents (either download/upload) users want to selectively enable/resume
3. "Test" torrents (bandwidth test, tracker test etc.)

Other users may have other uses. The above examples are outside the scope of Pause All/Resume All. This is mostly used for quickly stopping everything and freeing the internet connection to allow file downloads, web browsing etc. "Alternate Speed Limits" can help, but not always.
FranciscoPombal
Member
Member
Posts: 54
Joined: Wed Sep 09, 2020 10:34 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by FranciscoPombal »

I won't address your points directly (at least for now), because I think we're just shouting past each other.
I think I now know how to address the real issue. Let's focus on 2 points:

1) Why do have to use "resume all" at all, frequently? Do you always pause torrents that you are actively interested in before shutting down the client every time?

2) Even if you have a legitimate use-case to justify 1), from what you're describing, it seems to me that what you really want is some kind of "archive" state. You would put torrents into this "archived" state when you just want to leave them in the client for future reference, possibly even with missing files. The client wouldn't submit such torrents to as many checks when in this state. In this state, torrents would not be resumed with "resume all", they would have to be "un-archived" (or "restarted", if you will). I do think "archive" is a better abstraction that "stop" here, because it is a little more general, in that it encompasses the possibility of missing files, among possibly other things. Well, such a feature has already been requested on GitHub (more than once, actually, IIRC).

Is my reading of the situation correct?
ThyTorrenter
Member
Member
Posts: 20
Joined: Mon Jul 07, 2014 11:37 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by ThyTorrenter »

1a.I did not use Resume All frequently, many years ago when I was a uT user, but I did use it occasionally. I don't use it at all on qB, because it will Resume everything and I have adapted to avoiding Resume All. It's not a critical feature, but it would be nice to have.
1b. I don't pause torrents every time before shutting down qB. Never do, not sure why you asked that.

2. About "archived" state: I searched a bit and found this request. Yes, more or less I mean something like that, although my only concern is to exclude torrents from "Resume All". Never considered torrent checks, startup time etc. "Archiving" sounds a bit like using qB as database software, and keeping inactive torrents around for years. That's not what I had in mind but yes, "archiving" will do what I'm asking perfectly fine.

I'll approach this from a different perspective, trying to explain why Pause/Resume All is currently not intuitive. These two settings are next to each other in qB, implying that they complement each other. Here's the problem though:

Resume All = Resumes ALL torrents
Pause All = Does NOT Pause all torrents, because the user is allowed to Pause single torrents

So, if the user has a few paused torrents (or just one), then needs to Pause All without closing qB (to download a large file at full speed, Web-browse something or whatever, it's not uncommon to need bandwidth) and then Resumes All, the logic is broken. We are Resuming MORE torrents than those paused by Pause All. This is why I believe an additional "Pause" status is needed (Stopped/Archived etc. - naming is not the issue). Hope I made it more clear. :)
Last edited by ThyTorrenter on Tue Sep 22, 2020 4:44 pm, edited 1 time in total.
FranciscoPombal
Member
Member
Posts: 54
Joined: Wed Sep 09, 2020 10:34 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by FranciscoPombal »

ThyTorrenter wrote: Tue Sep 22, 2020 4:42 pm 1b. I don't pause torrents every time before shutting down qB. Never do, not sure why you asked that.
I was being a bit narrow-minded, and thinking there could only be one workflow that you were running into this, but where hitting resume all wouldn't make sense:

Because if you don't pause the torrents you are interested in before shutting down, why do you need to hit resume all when you start the client back up again the next time? They will all resume automatically on startup.

This doesn't matter now though, read on.
ThyTorrenter wrote: Tue Sep 22, 2020 4:42 pm
2. About "archived" state: I searched a bit and found this request. Yes, more or less I mean something like that, although my only concern is to exclude torrents from "Resume All". Never considered torrent checks, startup time etc. "Archiving" sounds a bit like using qB as database software, and keeping inactive torrents around for years. That's not what I had in mind but yes, "archiving" will do what I'm asking perfectly fine.

I'll approach this from a different perspective, trying to explain why Pause/Resume All is currently not intuitive. These two settings are next to each other in qB, implying that they complement each other. Here's the problem though:

Resume All = Resumes ALL torrents
Pause All = Does NOT Pause all torrents, because the user is allowed to Pause single torrents

So, if the user has a few paused torrents (or just one), then needs to Pause All without closing qB (to download a large file at full speed, Web-browse something or whatever, it's not uncommon to need bandwidth) and then Resumes All, the logic is broken. We are Resuming MORE torrents than those paused by Pause All. This is why I believe an additional "Pause" status is needed (Stopped/Archived etc. - naming is not the issue). Hope I made it more clear. :)
Ha! I think we found the root of the problem. "Resume all" really means "Resume all", it does not mean "Resume all torrents I have previously manually paused (with pause all)". With this in mind, I don't think there is anything wrong with the current behavior.

Now I understand exactly what you want. You want an additional state almost exactly like the current "pause" (with the same behavior regarding peer connections), but that doesn't get affected by "resume" or "resume all" - it needs a more "powerful" button to be reverted. At the same time, you don't exactly need all the features that an "archive" state would provide, as it is commonly described.

If this is the case, then, for disambiguation purposes, I would suggest referring to such a state as "frozen"/"freeze" (or something similar, that's not "stop"). This way, everyone understands that this has nothing to do with the classic uTorrent "stop"/"pause" discussion, and its implications regarding the tearing down of peer connections.
ThyTorrenter
Member
Member
Posts: 20
Joined: Mon Jul 07, 2014 11:37 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by ThyTorrenter »

FranciscoPombal wrote: Tue Sep 22, 2020 6:35 pm"Resume all" really means "Resume all", it does not mean "Resume all torrents I have previously manually paused (with pause all)". With this in mind, I don't think there is anything wrong with the current behavior.
Didn't say it is wrong, but unintuitive. The one function does not complement the other. But now that you mention it, even the wording is wrong: "Resume All" does indeed resume all, but "Pause All" does not pause all! "Pause Torrents" would have been more accurate.

Also, unless a user permanently runs qB with paused torrents, Pause All always comes first. So, the user first "Pauses All" 9 torrents, and then "Resumes All" 10 or more torrents. Unintuitive. By the way, "Pause All" would feel more correct if positioned ABOVE "Resume All" for this reason. Same with the Edit menu Pause/Resume positions.
FranciscoPombal wrote: Tue Sep 22, 2020 6:35 pmYou want an additional state almost exactly like the current "pause" (with the same behavior regarding peer connections), but that doesn't get affected by "resume" or "resume all"... ...I would suggest referring to such a state as "frozen"/"freeze.
I'll just add myself to those requesting the Archived state, no need to overcomplicate things! Would a hypothetical Archived torrent perform a full recheck every time it is started? That would be a problem, especially with large torrents. If there's no full recheck, Archive status would be perfect.
Last edited by ThyTorrenter on Wed Sep 23, 2020 11:21 pm, edited 4 times in total.
FranciscoPombal
Member
Member
Posts: 54
Joined: Wed Sep 09, 2020 10:34 pm

Re: Paused Torrents Un-Pause Upon Restart

Post by FranciscoPombal »

ThyTorrenter wrote: Wed Sep 23, 2020 11:13 pm Didn't say it is wrong, but unintuitive. The one function does not complement the other. But now that you mention it, even the wording is wrong: "Resume All" does indeed resume all, but "Pause All" does not pause all! "Pause Torrents" would have been more accurate.

Also, unless a user permanently runs qB with paused torrents, Pause All always comes first. So, the user first "Pauses All" 9 torrents, and then "Resumes All" 10 or more torrents. Unintuitive. By the way, "Pause All" would feel more correct if positioned ABOVE "Resume All" for this reason. Same with the Edit menu Pause/Resume positions.
I fail to see how the current behaviour is unintuitive. If you have 10 torrents, 1 paused, 9 resumed, and you clicked "Pause All", it causes ALL torrents to make a transition to the "paused" state; more specifically, the following happens:
- 1 paused torrent makes the following state transition: Paused -> Paused; the operation is idempotent in this case of course - it is as if nothing had happened
- 9 resumed torrents make the following state transition: Resumed -> Paused.

In other words, "Pause all" is idempotent w.r.t. torrents that are already paused. I think this is the most intuitive behavior.
Neither "Pause All" nor "Resume All" have any memory of what was pressed before, and which torrents were actually affected by such past actions. They just cause all torrents to make a certain state transition to a certain target end state (paused or resumed, respectively) at the time of pressing. If the torrent is already in the target end state at the time they are pressed, the operation on those torrents is idempotent.

But this is offtopic now...
ThyTorrenter wrote: Wed Sep 23, 2020 11:13 pm I'll just add myself to those requesting the Archived state, no need to overcomplicate things! Would a hypothetical Archived torrent perform a full recheck every time it is started? That would be a problem, especially with large torrents. If there's no full recheck, Archive status would be perfect.
IMO, "freeze" is different enough from "archive" to warrant its own separate feature request. In fact, one of its selling points is that it's "lighter-weight". The point about the recheck is an important distinction also. Go make your voice heard on the issue tracker!
Post Reply