mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Prioritize by file order #2344
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#2344
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 @Supranon on GitHub (Apr 5, 2015).
I've recently made the move to qbittorrent and I've only found it lacking in one minor feature. I think it would be great if you could select the files in the content of the torrent and choose prioritize by file order so that it prioritizes downloaings the files in order.
@chrishirst commented on GitHub (Apr 5, 2015):
Actually, it probably wouldn't, priority is set on pieces not 'files' and as the 'natural' order of files within a payload is 'largest file first' the pieces may not be in the order that you expect.
@usernamex01 commented on GitHub (Apr 10, 2015):
Yes it does. stop saying that it doesn't because we've been using it.
I agree that priority is set on pieces not 'files' and that is why we are asking for "prioritize by FILE ORDER"
I also want this feature. People keep saying sequential download is bad, well that wasn't what we we're asking for in the 1st place. Prioritize by file order is completely different from sequential download. I don't care how it downloads it as long as episode 1 or chapter 1 finishes 1st before episode 32 or chapter 99.
So let me try to break this down for everyone. Say for example I'm downloading a torrent with multiple files in them, maybe a season of a tv series, I want to download the episodes in order of their number like s01e01 first, then the 2nd one next like s01e02 so I can watch the 1st one when it finishes and it finishes 1st before the others in the list, while the others download again in order, and then the next number and then the next after each one finishes. I don't see how this is bad for the swarm, it just orders your downloaded files NOT the PIECES.
and this is the last and only reason I'm still using uTorrent.
@usernamex01 commented on GitHub (Apr 10, 2015):
Also please stop lumping this request in with previewing, it has completely nothing to do with it.
@bekaba commented on GitHub (Apr 11, 2015):
I actually just moved from utorrent 2.2.1 to vuze then tried qbittorrent. Both of those software have a feature that allow us to assign a priority number to each file (this is great when we want to download a serie with 15 files in it and want to watch them in order while downloading) and I can confirm that both software work for prioritizing files in the selected order.
I would love to have that feature in qbitorrent as well.
@usernamex01 commented on GitHub (Apr 12, 2015):
Right, I can see that, I know qbit has it, and once again. I'd like to be able to sort the files (already present) select them all, right click and prioritize by file order, and it does it automatically. Can anyone see the use and convenience of this feature? also the other app has more priority numbers 15 to 9 high, 8 to 5 normal and 4 to 1 low, qbit only has 3 max med and low, and you have to select manually for each and every file. If all the torrents i download only have 1 file in them, I'd be on qbit by now, been watching it for so long, wanna jump in for so long.
@chrishirst commented on GitHub (Apr 13, 2015):
libtorrent has only 7 levels of piece priority; and the difference between them mean that only the extreme ends and the middle one are significant
@usernamex01 commented on GitHub (Apr 18, 2015):
and once again, let me reiterate. Prioritize by file order is completely different from sequential download
and one more time.. I don't care about pieces. I only want to download the multiple FILES within a torrent in the ORDER that I Sort them with. chrishirst, I couldn't be any more blunt than this, I'm sorry, you're a mile off the mark, so you could understand better what I'm trying to say, please try using uTorrent, and try doing what I described above complete with screenshot, then maybe you will understand that what you're explaining has absolutely no bearing with the original TS request, and my own.
@chrishirst commented on GitHub (Apr 18, 2015):
I gave up using uTorrent a long time ago.
What you are missing is that uTorrent uses completely different protocol engine, their own closed source engine, which has different 'priority levels' to libtorrent, 15 as opposed to libtorrent's 7 and because of the native file sort order (largest first) and cross-file pieces in a payload with many files, the 'pieces' are unlikely to be in the order that you expect, so the result or ordering by file names is most probably not going to actually make any significant difference to the download order.
@bekaba commented on GitHub (Apr 18, 2015):
I m curious about something though, qbittorrent can prioritize 3 files without problem by using max, high and normal priority right? So when I download with it I can manually set max priority on file number 1, high on number 2 normal on 3 then the rest on do not download or normal and after each 2 downloaded files on max and high I set the following files that were on normal or do not download on max for number 3, high for n4 normal for n5 then the rest on do not download again then repeat the process until all files are done.
So this is actually possible to prioritize a large number of files manually in qbittorent, why wouldnt it be possible to set a function in qbittorent to automate that process?
@chrishirst commented on GitHub (Apr 18, 2015):
Read these.
#524, #1896, #2781, #2021, #1472 .... There are probably more as well.
@bekaba commented on GitHub (Apr 19, 2015):
In one of those threads, you are saying "The bittorrent protocol does not have a concept of 'files' as such, only 'pieces' have priorities so 'file priorities' are never going to work as a 'typical home user' would expect." How come other bittorrent software like vuze make that feature work perfectly fine then ?
Edit: actually nevermind, dont answer that, I ll just stick to other software that have this feature.
@chrishirst commented on GitHub (Apr 19, 2015):
Vuze is does not use the libtorrent protocol engine
uTorrent does not use the libtorrent protocol engine.
BitTorrent does not use the libtorrent protocol engine.
kTorrent does not use the libtorrent protocol engine
Seeing the pattern yet??
@chrishirst commented on GitHub (Apr 19, 2015):
Oh by "the libtorrent protocol engine", I am referring to libtorrent-rasterbar which does not include:
libktorrent (kTorrent), Azereus Engine (Vuze), rlibtorrent aka libtorrent-rakshasa (rTorrent) or any of the other adaptations/versions of libtorrent there are around.
@chrishirst commented on GitHub (Apr 19, 2015):
Hey great idea!
wish I had thought of that :)
/sardonicism
@chrishirst commented on GitHub (Apr 19, 2015):
Let me put it another way.
If it was a really useful 'feature', that users really wanted and one that could be implemented in qbittorrent to provide some genuine advantage to ALL users ... ... Do you not think it would have been already implemented???
From a programming point of view it is a fairly trivial operation, but is is an 'expensive' operation in resources and of little or no benefit because of the limited priority options exposed/provided in the actual protocol engine.
@usernamex01 commented on GitHub (May 4, 2015):
@chrishirst
You seem to be running out of patience here. I'm not an end user who does not seem to understand what I'm talking about. It looks to me like a UI or operational feature that doesn't have anything to do the with libtorrent protocol engine. If you don't want to do it, skip it, let someone else take a look. Or if you're absolutely 100% sure it will never be implemented, just say so. You think it's a useless feature? well the fact that you yourself pointed out several other requests for the same thing probably means a whole lot of other people think it's useful. The other apps also think it's useful.. why not you?
I ain't complaining, I know it's a free/open application so..... I made a request.
We went on and on back and forth about the feature I want and how you understood what I'm saying, further pointing us over to the forum link about how qBitTorrent was, has, and is, being developed. Yeah I read it. Even before asking.
I never asked for it to be:
My anti-virus application.
My computer firewall.
My anti-spyware protection.
My media player,
My file manager.
My diary of all the media I have already watched.
My TV Schedule.
My digital music librarian.
Piece of advice.... If it wont be implemented, say so clearly on every request thread.
"NO, We will not Implement it, we never will, we think it's a useless feature, we can't do it, it's impossible, it's too expensive to do, please stop asking"
@chrishirst commented on GitHub (May 4, 2015):
True, it does not explicitly state any of those. However, by virtue of it being a open source application, coded and supported by volunteer developers giving up their free time to assist the project, those are all implied constraints on what will be or CAN be considered or implemented. Therefore, by the same 'open source' token, you are free to develop and test anything you consider vital and offer it for the consideration and inclusion of the maintainer ( currently @sledgehammer999 ) then it only comes down to one person's opinion of whether it is a pointless feature or not or 'expensive' in resources.
'Expensive' in monetary terms rules it out completely, unless some kind soul wished to provide an 'in perpetuity' license to qbittorrent for the use of whatever it is.
'Can't do it' or 'impossible to do it', which are usually because of external library constraints, also exclude the 'feature' from implementation. Or at least until such times as the library does make implementation possible, and in that case it is up to the person(s) who would like this feature to be available, to petition the library maintainers to include the necessary code to or expose the necessary properties or methods in their library to allow it to happen.
NB: The exact same constraints or requirements in the noted in first paragraph also apply to any request made to the library developers.
"Open source" does not mean that every 'feature' request from every user should be given consideration a priori. That will only happen should a project developer decide that it is worth implementing for the majority of users or at least a large proportion of users.
However I feel that this discussion has reached it's conclusion as a GitHub topic and should, if you so wish, can be continued at the support forum 'Cafe lounge' section.
@chrishirst commented on GitHub (May 4, 2015):
By the way.
I haven't run out of patience, nowhere even near in fact.
@sledgehammer999 commented on GitHub (May 5, 2015):
DISCLAIMER: I haven't read your wall of text/ranting between users.
I think prioritizing by file order could be possible. Hint: First prioritize the pieces belonging to the first file, with out caring if the download sequentially. Then prioritize the pieces of the second file etc... How well this bahaves depends on the underlying mechanisms of libtorrent. ie even though we prioritized first file pieces we could get some very small percentage of pieces belonging to other files too.
I think #182 is very relevant for this issue.
However, I cannot give any kind of ETA. As you can see the bug tracker is full of requests and bugs. I work on whatever I want basically....
@usernamex01 commented on GitHub (May 17, 2015):
Thank you sledgehammer999, this is all I wanted. No problem with ETA, I don't mind at all. I know y'all do this for free.
@dmytrokyrychuk commented on GitHub (Oct 18, 2015):
Hi, everyone.
I see a lot of complains about the hurt of prioritizing. Just wanted to note here that it's natural that some files in torrent is more valuable/desirable than others, and those files will be distributed to the number of peers faster. Prioritizing pieces inside single torrent is not more harmful than prioritizing torrents inside a torrents list. It is only my personal view of the situation.
@chrishirst commented on GitHub (Oct 18, 2015):
Setting file priorities and sequential downloading are not one and the same. In a multi-file payload the files are sorted in size order (largest first), so when a torrent client user sets 'priorities' it is probably not going to start with piece 0 then piece 1 and so on, as 'sequential downloading does.
@darkmorpher commented on GitHub (Sep 11, 2016):
Duplicate of #1861 & #1896
@emanuelserpa commented on GitHub (Sep 9, 2019):
Is this the issue about alphabetical download file order?
@d-bykov commented on GitHub (Feb 20, 2020):
I would really appreciate this feature implemented in qBittorrent. This is the only thing that stops me from switching from uTorrent to qBittorrent.
It's very useful when I want to start watching first episodes of a TV show while next episodes are being downloaded.
And, by the way, it's not mandatory for this to have 15 priority levels like uTorrent does. Even libtorrent's 7 levels should be enough on a decent internet connection to be able to download whole season while watching the first 6 episodes.
Also, I don't see any problems with cross-file pieces - just let it download a small piece of another file.
@Ultranium commented on GitHub (Feb 20, 2020):
Please implement it, it's quite handy when you need to watch a tv series or listen to an audiobook ASAP.
People, who tells "it's bad for swarm because everyone will just stop seeding after they downloaded the torrent", why do you say that?
If I want to prioritize files in specific order means only that I want to start watching my show faster, and only that, it has nothing to do with how long I'll keep seeding.
@emanuelserpa commented on GitHub (Feb 21, 2020):
A possible implementation is in this plugin for Deluge:
https://dev.deluge-torrent.org/wiki/Plugins/AutoPriority
@EverNife commented on GitHub (Dec 27, 2020):
Man, 2015, big year!
I think creating a macro to just click on the buttons that already exist is easier than implement this on qbit :D