starred/qBittorrent

Fork 0

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

Completed On sorting is in reverse #615

New issue

Closed

opened 2026-02-21 15:12:55 -05:00 by deekerman · 12 comments

deekerman commented

2026-02-21 15:12:55 -05:00

Owner

Originally created by @alexwyattdev on GitHub (Jul 3, 2013).

torrents completed on 5:22 5:25 5:47 and 5:54 should be in this order, but the program makes it backward, no matter how i click on the Completed on bar, it always show me that the last one which was completed is 5:22 and the first one is 5:54 which is like traveling in time backward. In the first picture the red circled area should be flipped upside down only, but not the others like its done on the second pic

Originally created by @alexwyattdev on GitHub (Jul 3, 2013). torrents completed on 5:22 5:25 5:47 and 5:54 should be in this order, but the program makes it backward, no matter how i click on the Completed on bar, it always show me that the last one which was completed is 5:22 and the first one is 5:54 which is like traveling in time backward. In the first picture the red circled area should be flipped upside down only, but not the others like its done on the second pic ![image_2013-07-03 0604 49 148](https://f.cloud.github.com/assets/4926751/741078/071a3406-e396-11e2-9f4e-fab682445ffc.jpg) ![image_2013-07-03 0605 02 187](https://f.cloud.github.com/assets/4926751/741079/0a6d6222-e396-11e2-9b41-ab042d38fdbb.jpg)

deekerman closed this issue

2026-02-21 15:12:57 -05:00

deekerman commented

2026-02-21 15:12:59 -05:00

Author

Owner

@Gelmir commented on GitHub (Jul 3, 2013):

I don't see how this is a bug or I just don't understand.
First picture uses ascending sort and is sorted right: unfinished first, then finished torrents in completion order.
Second one uses descending sort and is, too, sorted right: finished torrents in reverse completion order first, then unfinished torrents.

@Gelmir commented on GitHub (Jul 3, 2013): I don't see how this is a bug or I just don't understand. First picture uses ascending sort and is sorted right: unfinished first, then finished torrents in completion order. Second one uses descending sort and is, too, sorted right: finished torrents in reverse completion order first, then unfinished torrents.

deekerman commented

2026-02-21 15:13:00 -05:00

Author

Owner

@alexwyattdev commented on GitHub (Jul 3, 2013):

well its in reverse, because 5:22 is "older" than 5:57, I mean in time 5:22 was completed first, and not 5:57, it feels like the program determines completed on as if the bigger number equals the older, which is chronologically incorrect. As for me it would be more logical to put the newest after the unfinished ones, because the unfinished ones will be the "new newest" finished torrents. maybe its my fault, just got used to the utorrent and others' sorting method

@alexwyattdev commented on GitHub (Jul 3, 2013): well its in reverse, because 5:22 is "older" than 5:57, I mean in time 5:22 was completed first, and not 5:57, it feels like the program determines completed on as if the bigger number equals the older, which is chronologically incorrect. As for me it would be more logical to put the newest after the unfinished ones, because the unfinished ones will be the "new newest" finished torrents. maybe its my fault, just got used to the utorrent and others' sorting method

deekerman commented

2026-02-21 15:13:00 -05:00

Author

Owner

@Gelmir commented on GitHub (Jul 3, 2013):

Well, µTorrent (1.8.5 at least) uses the same approach.

@Gelmir commented on GitHub (Jul 3, 2013): Well, µTorrent (1.8.5 at least) uses the same approach.

deekerman commented

2026-02-21 15:13:00 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 3, 2013):

I think this is matter of context. To me, when refering to time, ascending order means "older to newer" and descending order means "newer to older".

As for me it would be more logical to put the newest after the unfinished ones, because the unfinished ones will be the "new newest" finished torrents.

About I think you are correct. We should swap the position of unfinished ones and treat as the newest entries in the list.

@sledgehammer999 commented on GitHub (Jul 3, 2013): I think this is matter of context. To me, when refering to time, ascending order means "older to newer" and descending order means "newer to older". > As for me it would be more logical to put the newest after the unfinished ones, because the unfinished ones will be the "new newest" finished torrents. About I think you are correct. We should swap the position of unfinished ones and treat as the newest entries in the list.

deekerman commented

2026-02-21 15:13:00 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 3, 2013):

Also I checked with utorrent 3.1.2 and it does the same. (didn't check unfinished ones though)

@sledgehammer999 commented on GitHub (Jul 3, 2013): Also I checked with utorrent 3.1.2 and it does the same. (didn't check unfinished ones though)

deekerman commented

2026-02-21 15:13:00 -05:00

Author

Owner

@alfrix commented on GitHub (Jul 11, 2013):

The unfinished torrents should be on the other end of the list, because the completion time of them, will be newer than the rest, that is how utorrent always handled it...

Also #106 requested the same thing

@alfrix commented on GitHub (Jul 11, 2013): The unfinished torrents should be on the other end of the list, because the completion time of them, will be newer than the rest, that is how utorrent always handled it... Also #106 requested the same thing

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 11, 2013):

Also #106 requested the same thing

Good catch.

Currently working on this, so unfinished torrents are sorted correctly.

@sledgehammer999 commented on GitHub (Jul 11, 2013): > Also #106 requested the same thing Good catch. Currently working on this, so unfinished torrents are sorted correctly.

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 14, 2013):

I think it is even better to always sort invalid dates at the bottom.

@sledgehammer999 commented on GitHub (Jul 14, 2013): I think it is even better to always sort invalid dates at the bottom.

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@alfrix commented on GitHub (Jul 14, 2013):

i would swap the position of the uncompleted as @kiskunk said
And add a little thing: if there is a queue number on the item that has an invalid date, follow them to sort the list
Illustrating this:

@alfrix commented on GitHub (Jul 14, 2013): i would swap the position of the uncompleted as @kiskunk said And add a little thing: if there is a queue number on the item that has an invalid date, follow them to sort the list Illustrating this: ![sort](https://f.cloud.github.com/assets/1247237/794983/ccc4f566-eccd-11e2-9cb2-d418440e8acc.JPG)

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Jul 14, 2013):

I want to hear the input from all of you. Is it better to always sort the uncompleted ones at the bottom or only when the sorting order is ascending?

And add a little thing: if there is a queue number on the item that has an invalid date, follow them to sort the list

Please open a new issue so we can track this. It will get lost here.

@sledgehammer999 commented on GitHub (Jul 14, 2013): I want to hear the input from all of you. Is it better to **always** sort the uncompleted ones at the bottom or only when the sorting order is ascending? > And add a little thing: if there is a queue number on the item that has an invalid date, follow them to sort the list Please open a new issue so we can track this. It will get lost here.

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@Belove0 commented on GitHub (Jul 16, 2013):

Since you called for opinions :)
I would prefer incompletes to be sorted on the "future" end, and not always be at the bottom (or top), but I can imagine motives for desiring either case. Dropping them at the end suggests the user is primarily interested in completed torrents. Sorting them in "future" position (my favorite) allows a handy descending-order view when the user is interested in currently downloading items more than completed items, followed by the most recent completions (this is a nice view to track downloads).

@Belove0 commented on GitHub (Jul 16, 2013): Since you called for opinions :) I would prefer incompletes to be sorted on the "future" end, and not always be at the bottom (or top), but I can imagine motives for desiring either case. Dropping them at the end suggests the user is primarily interested in completed torrents. Sorting them in "future" position (my favorite) allows a handy descending-order view when the user is interested in currently downloading items more than completed items, followed by the most recent completions (this is a nice view to track downloads).

deekerman commented

2026-02-21 15:13:01 -05:00

Author

Owner

@ghost commented on GitHub (Jul 16, 2013):

Will be perfect if you allow two-stage sorting. First sort by "Status", and then sort with shift by "Completed on" (exactly like in µTorrent)

@ghost commented on GitHub (Jul 16, 2013): Will be perfect if you allow two-stage sorting. First sort by "Status", and then sort with shift by "Completed on" (exactly like in µTorrent)