mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Option to always add new downloads to top of queue #9413
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#9413
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SirGouki on GitHub (Dec 6, 2019).
Originally assigned to: @glassez on GitHub.
As the "issue" name suggests, add an option for Adding new downloads to the top of the queue. My recommendation is to add a global option that automatically adds ALL new downloads to the top of the queue, adding a tickbox on the new download window, as well as adding an option to the RSS downloader rules so that files downloaded via RSS automatic downloads can be added to the top as they come in.
A use-case for this could be: I have an open video series that posts once a week that I want to always download as soon as it comes out so I can watch it while I eat dinner. I also have an archived set of files I'm trying to download to restore another computer but it's taking a while due to low internet speeds, but once my video downloads, any new videos come after this archive due to it being higher in the queue. I would instead prefer for the new videos to be placed at a higher position, so that my archive temporarily pauses as the videos are more important to me than the archive currently is. I know at least a couple other people would like this as well as I was going to sign up to the forums specifically to post this and saw their post, followed by the one that states to post this here instead.
@Wizek commented on GitHub (Mar 26, 2020):
I'm also interested in this. @thalieht or @FranciscoPombal if this is a duplicate, which GH issue is this the duplicate of? This comes up first for me on Google.
@thalieht commented on GitHub (Mar 26, 2020):
#357 but that issue should be renamed just like this one if this is closed. I managed to find it through another issue.
@FranciscoPombal commented on GitHub (Mar 26, 2020):
I chose to to close the other one as the OP account was deleted, and there were lots of "+1" comments. And even though the other has a more concise description, this one presents a detailed use-case example which is useful for everyone who stumbles upon this to understand it better.
@Medvedishce commented on GitHub (Mar 26, 2020):
Please correct statuses - see my comment in #357.
#357 is a predecessor, #11599 needs to be closed and marked as Duplicate!
@FranciscoPombal commented on GitHub (Mar 26, 2020):
@Medvedishce
A predecessor issue may be closed as duplicate in favor of a newer version. The end result in terms of duplication of issues is the same.
I gave my reasons for superseding https://github.com/qbittorrent/qBittorrent/issues/357 with this one here: https://github.com/qbittorrent/qBittorrent/issues/11599#issuecomment-604624448 (you have to expand it because I marked it as resolved).
@Medvedishce commented on GitHub (Mar 26, 2020):
@FranciscoPombal - It's your decision and it will be your responsibility. At least you mast know that you not only cut long lived brunch with plenty of real life comments, you also cut all links done in other requests which do reference old request.
I will not sue your resolution to start new brunch - your reasoning to do it is solid I think.
But if you start, then you must do a plenty of other jobs - please do not stop at one superseding reference. Please open each request which had references to old request and add references to new main request replacing old head of brunch. Yes it's plenty of work but this must be done. If you do not do it, then all our interests and contributions were deemed for nothing.
At least I will edit my reference to here and reference from here.
You do all other.
@Medvedishce commented on GitHub (Mar 26, 2020):
I suggest to add both options and make Feature requests to be linked because both make prioritization in two different ways and it preferable to have both variants:
Add torrent to top priority option #357, Superseded by #11599
Add torrents in Forced state #11659
@FranciscoPombal commented on GitHub (Mar 26, 2020):
@Medvedishce
What are you even talking about? All other comments in https://github.com/qbittorrent/qBittorrent/issues/357 are useless clutter ("bump", "I need this as well", "+1", "any progress?", off topic conversations). So I closed it in favor of this one which has a cleaner slate. Sounds like you didn't understand my reasoning at all.
Plus https://github.com/qbittorrent/qBittorrent/issues/11659 is different enough that it deserves its own separate treatment. Remember the one issue report per problem policy in the issue report in the contributing guidelines. It's important to keep things focused.
Now with this useless discussion between us this issue report is becoming cluttered as well with unrelated comments...
By adding a reference to this issue in https://github.com/qbittorrent/qBittorrent/issues/357, all people who stumble upon the others that were closed as duplicates can still find their way here. No need to add a reference in all of them as well, it will just spam the notifications of everyone who is subscribing to all notifications. I will not do that and I ask that you please don't do that either.
@Medvedishce commented on GitHub (Mar 26, 2020):
Yes, you are right, this is useless discussion. Especially considering that I didn't discuss anything and only showed my point of view. So this will be my last comment here and I will not discuss it any more.
In other cases I wouldn't add additional comments but I can't miss that one statement: "All other comments in #357 are useless clutter".
All I can say - you will be bad jurist if you make such statement officially. This is called "twisting the facts".
For all who will read our comments I provide here real statistical information from #357:
there are 16 comments inside from which only 3 are useless clutter. Also there 4 (5 counting this one here) additional requests opened for the same issue each with thorough description from different points of view. 3 of 4 were closed as Duplicates and 1 still leaved opened in spite of been marked as Duplicate. All this represents history of small but unfading community interest for such feature development starting from Jan 2013.
And last one word about not understanding reasoning - I'm very well understand your reasoning but I didn't say I support all parts of it.
I understand and I think it is solid reasoning to close request which has the OP account deleted. At least you need to have responses and support from the author.
And I don't understand and don't support "closed it in favor of this one which has a cleaner slate".
Here you in turn do not understand my reasoning: you are cutting and throwing in the trash all our discussions, questions, doubts, support as "useless clutter".
About this part of your decision I pointed you as "it will be your responsibility" as a [Member].
All supporters and contributors look on project in its whole by judging [Member]'s decisions and here you, as part of officials bore grave responsibility for your actions and statements, even if not directly pronounced.
That's all I tried to say in my comments previously, sorry all for it took so many words to precisely express my thoughts.
@FranciscoPombal commented on GitHub (Mar 26, 2020):
@Medvedishce
All right. I'll take the bait.
Since everything is properly linked, closing (cluttered) duplicates does not erase the "history of small but unfading community interest for such feature development starting from Jan 2013.". It re-focuses the discussion and makes it more productive.
Github back then was different. There were no comment reactions, so people commented a lot with "+1"/"me too", which is bad practice now (even our contributing guidelines say that).
Again, closing and issue as duplicate/superseding it does not mean the support is not being valued or thrown away. It actually means people, including me, still care and want to make it more visible and clear. If I didn't care aobut the issue or the support for it, I'd just leave it abandoned.
So let's see if I "twisted the facts" or threw relevant things in the trash:
This issue tracker has too many issues open (most of them should be closed, for many different reasons) that prevent contributors from focusing on what's important. Over the past weeks/months I've been tagging and closing issues to at least keep things under control until the stale bot or similar is deployed. The idea is to keep all relevant information in as little number of comments/open issues as possible to keep the discussion sane and focused.
I'm doing my part to keep this project alive and manageable. Think about what that means before accusing me of throwing useful information away. If you want chit-chat go to the forums.
@SirGouki commented on GitHub (Mar 27, 2020):
I apologize that I opened this while similar issues were opened, I was still new to git hub when I did this one. I also didn't realize that asking for this would be grounds to start arguing in the comments to the request. Can we please get it together and focus on the facts: 1) Yes there's demand for this feature, and 2) the comments to issues are not the place to argue in front of everyone. Again, it was not my intent to cause problems here, I just thought it would make the best torrent client out there better.
Also, due to the shear amount of emails I've been getting about this, I've unsubscribed to this issue. If it gets added, or you decide its not useful, congratulations on progress. If I could have done it myself, I would have posted a way to fix it or I would have submitted a PR myself as a response, but instead I thought it better to leave it to people that know the code better than myself.
@FranciscoPombal commented on GitHub (Mar 27, 2020):
@SirGouki
No need to apologize. This isn't your fault. Sometimes things like this happen, it's the nature of FOSS development.
Things like this are precisely what I wanted to avoid, but it's a lose-lose situation - leaving misinformation unaddressed is counter-productive, but so is engaging in the discussion at all.
If you know how to code and want to take a stab at this, feel free to submit a PR. People will try to help you with what you need. If you think the initial state of the PR will be too "rough", submit it as a draft PR.
@UnconditionalLoop commented on GitHub (Oct 18, 2020):
Why is this feature still not available? It has been requested since 2013.
#357
#1966
Like what the hell man, just add the feature. It will take all of 5 seconds. Just have a goddamn option to put newly added torrents at the top of the queue. It's not that hard.
@FranciscoPombal commented on GitHub (Oct 19, 2020):
@watsondevelopment
Why don't you contribute the feature yourself, then? This is FOSS, you don't get to demand that others do shit for your entitled self.
@taylorcjensen commented on GitHub (Mar 22, 2021):
This is a reasonable request and while nobody is forcing anyone to do anything, it would be nice if the developers weren't so antagonistic about their lack of interest in supporting it.
@cemma89 commented on GitHub (Dec 9, 2021):
I love qBittorrent and appreciate the volunteer work people put into it, but I gotta say this is one of the first issues I noticed when I started using this over a decade ago and I'm pretty surprised it hasn't been added. I assumed it had been long ago and I was just blind. It doesn't make much sense to me: if the 'start downloading immediately' checkbox is selected upon adding a link, the behavior is to sandwich it somewhere down the list and not start downloading immediately until everything else is finished? It effectively adds four extra clicks and a wordsearch to what every other torrent client does by default?
I admit I'm rather useless and not a programmer so I hate complaining when I can't contribute much. But please add this feature someone, it is basically the only reason I would consider using another client.... qBittorrent has so many features that 90% of users will never touch and I think it's great, but this is a simple one that a lot of people would appreciate I think.
Sorry if this sounds entitled but I am just adding my voice to the pile in case there are any doubts that people don't miss the presence of this feature.
@austinamorusoyardstick commented on GitHub (Jan 20, 2023):
The solution to this is already possible and available you only need to:
(Assuming you are running on linux and have the webui running with your ability to not require login on localhost
Run external program on torrent added:
@cemma89 commented on GitHub (Jan 20, 2023):
Windows, but now that you mention it I don't know why I need my torrent
client to run on my gaming pc...
On Fri, Jan 20, 2023, 8:05 PM Austin Amoruso @.***>
wrote:
@ghost commented on GitHub (Jan 29, 2023):
This is the only gripe I have with qBittorrent. Otherwise my favorite torrent downloader. Having to move the files up the "#" column every time I add a new download is a bit tiresome and this seems like a feature that would have been added early on.
Hope it's implemented in the near future.
@UnconditionalLoop commented on GitHub (Jan 31, 2023):
If I wasn't lazy, I could have just added this option myself a year ago in
about 10 minutes. People requested this back all the way to 2013. I know
multiple people have already made their own personal branches just for this
one option.
On Sun, Jan 29, 2023, 7:43 AM Icoch @.***> wrote:
@glassez commented on GitHub (Jan 31, 2023):
Die Geschichte kennt kein Wenn
© Karl Hampe
Everyone has such "ifs".
If to the point, I've added this to my to-do list.
@ghost commented on GitHub (Jan 31, 2023):
If sharable, please let me know!
Cheers
@glassez commented on GitHub (Feb 4, 2023):
#18518