#24925·qBittorrent

Moving Group of Selected Torrents to Bottom Lags

Author: BattouSaeenCreated Sep 17, 2026Updated Sep 17, 2026
LabelsPerformanceGUI

qBittorrent & operating system versions

Win 10 x64 22H2 Qt: 6.10.3 Libtorrent: 1.2.20.0 Boost: 1.86.0 OpenSSL: 3.6.3 zlib: 1.3.2

What is the problem?

Selecting a group of torrents at some arbitrary point, either contiguously or separated, and then moving them to the bottom of the queue (and sometimes top), usually has a strange lag, and the group moves very slowly through the transfer list one by one, even though their queue numbers have already been updated correctly.

E.g. 2000 torrents Select a group of them, say from 10 to 20 Move to bottom of queue Their numbers will update fine -> 1980 to 2000 But they will visually remain more or less where they were (in the 10-20 range) and slowly move, replacing the next listing. So it'll look something like this:

Image

Compared to 4.2.5, this happened as well, but it was much faster in resolving. i.e. there would be a brief moment that these selected torrents would "lag behind", but then in a few moments they'd all go away. Maybe 30-50% of the time, they would not, and I'd need to switch filters or views and come back for them to be gone.

In the case of the current version, they lag around 80-100% of the time. i.e. sometimes they don't lag and just move to the end as expected, but most of the time they will get stuck. Unlike 4.2.5, they will also remain stuck for much longer.

In both 4.2.5 and current version, there will be times that the group will break. E.g. in the screenshot above, I actually selected a much bigger group and sent them to the end, but 4 of them moved one position and then got stuck, the rest moved to the end.

It's a very strange thing I don't know how else to describe it, so I hope this was clear enough. It feels like the maths correctly works (since the queue numbers update instantly) yet there is something on the GUI side that is keeping them stuck or slow or whatever.

I recall sometime back there was an issue in the GUI generally being much slower than older versions, especially when loading the Content tab. I wonder if the fix for that somehow made this worse unintentionally.

Additionally, I also wonder if this might be related to the issue of a torrent jumping to the end when initiating a force recheck. In 4.2.5, if the torrent is running, a force recheck will send it to the end. But if it's paused, a force recheck will keep the torrent in its place (which I prefer, and would like it to remain in place even if it weren't paused). But in current version, it doesn't matter if it's paused or not, it will always move to the end of the queue when forcing recheck.

In general, the whole way the transfer list works seems to be much different as evident from my other issue from sometime back about the sorting columns logic change.

Steps to reproduce

  • Have many torrents (unlikely to reproduce on just a few)
  • Select a group, preferably somewhere other than the very top of the queue
  • Move them to the back (not sure if it happens with moving to front, but I think it does)

Additional context

No response

Log(s) & preferences file(s)

N/A