Sort by progress, bug or feature

[veldt]

In at least 2.20b1 (11752), but not in (some) earlier versions, like probably 2.04, which had the nicer sorting:

View / sort by progress:

Progress bar always represents portion of desired files completed.

When all selected files in a torrent are done, text is "X of Y (Z%)", where X is size of downloaded files, Y is total size of torrent, and Z is that percentage.

When all selected files in a torrent are not yet done, text is "X of Y (Z%)", where X is size of downloaded files, Y is *size of selected downloads when all are complete*, and Z is that percentage.

The sort-by-progress always goes by the first of the above, even when the second is displayed.

Can this be done?: always display and sort by the second. With non-reversed sort order, this puts all torrents whose chosen files are not all yet done at the bottom. As it is now, such a torrent can be found at various places among the done-torrents-containing-some-"do-not-download"-files, with its percentage displayed calculated differently from such... dtcsdndf's , so the percentages on-screen are not strictly increasing or decreasing, so to the user it looks like "Sort by Progress" is broken. As well, the not-yet-done torrent will have a not-full progress bar, yet often will have torrents with full progress bars above _and_ below it.

Thanks.

[veldt]

Hi. I agree with jordan when he says in https://trac.transmissionbt.com/ticket/3770#comment:4, "I agree with synchronizing the clients' sort modes...". Mac, qt and gtk clients should sort the same. I will go into deeper reasoning if necessary, but it sounds like the sorting algorithm for the Mac client described 11 months ago by livings124 in https://trac.transmissionbt.com/ticket/3080#comment:5 is borked, no offense intended! And if the Mac client indeed uses it -- I will try to test it soon -- then it is borked relative to the pre-11446 transmission-gtk behaviour. Here is a one-line change that makes the transmission-gtk client sort beautifully again; this would please both myself and porg from ticket 3090; we are both saying that progress toward "done" is more important to most users(*) than progress toward "complete" given that "complete" may not be a "goal" at all for partial downloads to progress toward. He was not at all disagreeing with livings124's definition of "ratio". livings124 states a definition of progress differing from pre-11446 transmission-gtk's, saying progress = %complete, not %done, but does not really defend it, merely disagreeing with what he saw as porg's definition of "ratio". A re-reading of 3090 should show that despite using the word "ratio", porg was talking about sort key 1, "progress", when he said "selected" should trump "complete (total)". I agree; he goes on to say that the rest of the sort keys, including "ratio", are fine as they are.

I can't seem to attach a patch here, but I hesitate to post a ticket reversing previous invalid and fixed enhancement treatments yet. This is versus svn grab as
of 11833:
diff -r latest/tr-core.c fixed/tr-core.c
437c437
< if( !ret ) ret = compareDouble( sa->percentComplete, sb->percentComplete );
---
> if( !ret ) ret = compareDouble( sa->percentDone, sb->percentDone );

This looks *so* much better.

(*) The only complaint with this behaviour was from a transmission-gtk user in https://trac.transmissionbt.com/ticket/3770, asking for the sorting behaviour described for the Mac client 11 months ago to have complete seeding torrents progress-sort above all non-complete seeding torrents. As a default sort, this is far less elegant than the previous behaviour in practice. There are numerous enhancements which would enable his desired behaviour as an option:
- a preference "Progress sort by torrent size" (rather than by "done" size)
- a new "View" menu item, "Sort by completion"
- new filters -- but this is cumbersome -- "Seeding completed" and "Seeding partial"

[veldt]

I'll most likely post some sort results within the week (my brother's getting engaged ..and I have to get my parents to stop sleeping their Mac so I can get to it to do some tests via vnc :-]

[veldt]

Current version, sorted by highest progress first, screenshot:

1+2: Top 2 torrents: This is the end of the range of 100% complete, 100% done, seeding torrents, sorted by descending ratio. Full progress bars.

3: seeding, 100% done, partial torrent, 86.9% complete, ratio 0.15. Full progress bar, percent figure displayed "86.9%". (Usability note: Full progress bar indicates all selected files are done, 86.9% figure indicates more could be downloaded if desired. That's fine.) [problems: Torrents with a very low ratio sort above this one, and other 100% done partial torrents with a higher ratio will be sorted lower.]

4: 78.8% complete, 78.8% done torrent, ratio 0.02. Progress bar at 78.8%, percent figure displayed "78.8%". [problem: 100% done torrents appear lower than this 78.8% done torrent.]

5: 55.3% complete, 55.3% done torrent, ratio 0.00. Progress bar at 55.3%, percent figure displayed "55.3%". [problem: 100% done torrents appear lower than this 55.3% done torrent.]

6: seeding, 100% done, partial torrent, 50.0% complete, ratio 0.09. Full progress bar, percent figure displayed "50.0%". [problem: This torrent has a full progress bar yet the one above it -- despite sorting by progress -- does not.]

7: 34.8% complete, 88.8% done partial torrent, ratio 0.15. Progress bar at 88.8%, percent figure displayed "88.8%". [problem: a 55.3% done torrent with a 0.00 ratio occurs higher than this 88.8% done torrent with a ratio of 0.15; this torrent has a fuller progress bar. It should be higher.]

8: seeding, 100% done, partial torrent, 30.8% complete, ratio 0.75. Full progress bar, percent figure displayed "30.8%". [problems: a 100% done torrent with a ratio of 0.09 sorts before this 100% done torrent with a ratio of 0.75. This seeding done torrent with full progress bar occurs after the still-downloading, 88.8% progress bar torrent preceding it.]

Thanks as always.