mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Possibility to enable sequential download #6067
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#6067
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 @silverqx on GitHub (Sep 14, 2017).
I want to suggest PR, where will be possible to enable sequential download per whole app and per torrent.
The checkbox, which will control whole app, might be in
Downloads - When adding a torrent - Enable Sequential download.For per torrent it will be in
Add new torrent modal - Torrent settings - Sequential download.When checkbox will be checked in
main options, so checkbox inadd new torrent dialogwill be checked by default and vice versa.Of course, on the defaults this checkbox will be unchecked, so nothing changes and the default behavior will be like it's now.
Personal experience, on my mmc comp, where i'm downloading only movies, need seq. download in 99% cases, but on my dev. comp, I don't need seq. download at all, would be very helpful to control this behavior.
@zeule commented on GitHub (Sep 14, 2017):
These changes were disputed many times already. They are absent because otherwise it would be to easy to damage the cloud. But, perhaps, we can add options to automatically enable them when a torrent is super-healthy? For example, when availability is higher than 10.
@silverqx commented on GitHub (Sep 14, 2017):
Absolutely, this is good suggestion, so when user selects
Download in sequential orderfromtransferlistwidgetcontext menu, so availability will not be checked, like it is now.But when it will be selected through checkbox in
main optionsor selected through checkbox inadd new torrent modal, so availability should be checked, e.g. should be higher than 10.So the behavior will be, e.g. this checkbox will be checked in main options, torrent will be added and download starts normally, not like
sequential download, but when the availability will be higher than 10. torrent will be switched tosequential download.The other protection could be, that this auto seq. download should work for movies only, but this may be later and in other task.
@zeule commented on GitHub (Sep 14, 2017):
@glassez, this auto enabler/disabler fits perfectly into categories approach. How do you think, would it be possible to design them in a way that category would not be bound to save path forcing, but at the same time can manage other settings?
@glassez commented on GitHub (Sep 14, 2017):
@evsh, I think Yes. I want to make save path binding optionally as other (possible) per-category settings.
@zeule commented on GitHub (Sep 14, 2017):
Superb.
@silverqx commented on GitHub (Sep 14, 2017):
I looked at
AddNewTorrentDialogand there is nothing to prevent other settings from being bound to category, it'sAddNewTorrentDialog::categoryChanged()slot.@silverqx commented on GitHub (Sep 18, 2017):
I have this almost done, i'm doing on last thing and need to know, where are this data persisted https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/torrenthandle.h#L458.
I need to save one bool value, but per torrent, it is value if the Sequential download was overridden in Add new Torrent dialog.
@thalieht commented on GitHub (Sep 18, 2017):
You mean where they are saved in the .fastresume files? https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/torrenthandle.cpp#L1669 and read from https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/session.cpp#L4289
But i'm curious why do you need to save that.
@silverqx commented on GitHub (Sep 18, 2017):
Thx, this is it :)
Sequential download will be intelligent, so if the availability drops under 10 and torrent is active and is in downloading state, seq. download will be disabled and if availability increases above 10, seq. download will be enabled.
We need to persist this, because of course qbittorrent can be exit and launched again and on the basis of seq. download checkbox in add new torrent modal dialog will be decided, if seq. download for torrent will be enabled :).
@siran commented on GitHub (Sep 26, 2017):
I totally agree with this. If torrent is healthy, there should be an option to download sequentially/first last part first by default.
Currently I only have one active download torrent at once, so if downloading a 2nd torrent I need to click 8 times so the 2nd torrent can download sequentially and first/last pieces first:
1- right click on 2nd torrent
2- click on force download (... wait until it starts...)
3- right click on 2nd torrent
4- click on sequential order
5- right click on 2nd torrent
6- click on first and last pieces first
7- right click on 2nd torrent
8- click on resume download
:-/
@siran commented on GitHub (Oct 12, 2017):
UPDATE
I discovered that if you select a bunch of torrents, as long as one of them is downloading you can select Download in Sequential Order for all of them. Unfortunately, the "Download first and last pieces first" flag doesn't update this way.
@silverqx commented on GitHub (Oct 13, 2017):
@siran it's exactly the reason why I have proposed this project, to improve UX
@sledgehammer999 commented on GitHub (May 11, 2018):
Duplicate of #164
Also locking conversation: https://github.com/qbittorrent/qBittorrent/issues/164#issuecomment-388520313