After 4.2.0 the maindata endpoint that WebUI uses has a changed behaviour for completed_on #10785

New issue

Open

opened 2026-02-21 20:57:45 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-21 20:57:45 -05:00

Owner

Originally created by @ajohnsen on GitHub (Aug 6, 2020).

Please provide the following information

qBittorrent version and Operating System

4.2 docker from linuxserver

If on linux, libtorrent-rasterbar and Qt version

What is the problem

After upgrading to 4.2 the completed_on data that is returned for torrents for the maindata endpoint has changed.

Before the upgrade (<4.2):
If the torrent wasn't finished the number/date returned for completed_on was 4294967295, making them appear on top of the list (newest) when sorting by 'completed on' in the WebUI.

After the upgrade (>=4.2):
If the torrent isn't finished the number/date returned for the completed_on is now -3600, which puts this torrent at the bottom on the list (with the oldest finished torrents) when sorting by 'completed on'.

What is the expected behavior

Unfinished torrents shouldn't have completed on dates in the past, because that can never happen.
It should rather be like it was before where it stayed next to the recently finished.

Steps to reproduce

Sort by completed_on with unfinished torrents

Extra info(if any)

I first thought the issue was with the WebUI, but after some digging, I saw that the response from maindata had changed.
I'm not very familiar with c++ code, so I haven't been able to check it all. But I have a suspicion that it might have gotten introduced with this commit: github.com/qbittorrent/qBittorrent@2346bc8f7c

Related issues that have reported it for the GUI:
https://github.com/qbittorrent/qBittorrent/issues/11923
https://github.com/qbittorrent/qBittorrent/issues/11645 (I created this one when I originally discovered the change)

Originally created by @ajohnsen on GitHub (Aug 6, 2020). **Please provide the following information** ### qBittorrent version and Operating System 4.2 docker from linuxserver ### If on linux, libtorrent-rasterbar and Qt version ### What is the problem After upgrading to 4.2 the completed_on data that is returned for torrents for the maindata endpoint has changed. Before the upgrade (<4.2): If the torrent wasn't finished the number/date returned for completed_on was 4294967295, making them appear on top of the list (newest) when sorting by 'completed on' in the WebUI. After the upgrade (>=4.2): If the torrent isn't finished the number/date returned for the completed_on is now -3600, which puts this torrent at the bottom on the list (with the oldest finished torrents) when sorting by 'completed on'. ### What is the expected behavior Unfinished torrents shouldn't have completed on dates in the past, because that can never happen. It should rather be like it was before where it stayed next to the recently finished. ### Steps to reproduce Sort by completed_on with unfinished torrents ### Extra info(if any) I first thought the issue was with the WebUI, but after some digging, I saw that the response from maindata had changed. I'm not very familiar with c++ code, so I haven't been able to check it all. But I have a suspicion that it might have gotten introduced with this commit: https://github.com/qbittorrent/qBittorrent/commit/2346bc8f7c6300e09fd8fb734ccb15664fac8ea2 Related issues that have reported it for the GUI: https://github.com/qbittorrent/qBittorrent/issues/11923 https://github.com/qbittorrent/qBittorrent/issues/11645 (I created this one when I originally discovered the change)

deekerman added the

Discussion

WebAPI

labels

2026-02-21 20:57:45 -05:00

deekerman commented

2026-02-21 20:57:47 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Aug 6, 2020):

Closed the previous 2 issues, we only need one about this.

Here's the only other previous thought on this matter from another user (https://github.com/qbittorrent/qBittorrent/issues/11645#issuecomment-569986704):

I disagree that the change is "illogical", or that it represents a regression rather than an enhancement.

Quantitatively, an unfinished item is one that might finish in the future, which is closer to the recent past than the distant past. However, such a consideration is not the only that ought to determine the final behavior the user interface.

But practically, an item which has finished recently is of greater interest than one which has finished never or long ago. A sort prioritization that places newly finished items on the extreme end of the list is tremendously valuable. The former behavior made finding these items unnecessarily difficult by placing them in the midst of two less interesting categories.

The new behavior may not be the only that is correct or "logical", but neither is the old. Competing concerns must be weighed one against the other.

@FranciscoPombal commented on GitHub (Aug 6, 2020): Closed the previous 2 issues, we only need one about this. Here's the only other previous thought on this matter from another user (https://github.com/qbittorrent/qBittorrent/issues/11645#issuecomment-569986704): > I disagree that the change is "illogical", or that it represents a regression rather than an enhancement. > > Quantitatively, an unfinished item is one that might finish in the future, which is closer to the recent past than the distant past. However, such a consideration is not the only that ought to determine the final behavior the user interface. > > But practically, an item which has finished recently is of greater interest than one which has finished never or long ago. A sort prioritization that places newly finished items on the extreme end of the list is tremendously valuable. The former behavior made finding these items unnecessarily difficult by placing them in the midst of two less interesting categories. > > The new behavior may not be the only that is correct or "logical", but neither is the old. Competing concerns must be weighed one against the other.