starred/qBittorrent

Fork 0

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

Improvements when moving a huge torrent #415

New issue

Open

opened 2026-02-21 15:05:36 -05:00 by deekerman · 10 comments

deekerman commented

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

Owner

Originally created by @sledgehammer999 on GitHub (Mar 16, 2013).

Tracking upstream bug: https://code.google.com/p/libtorrent/issues/detail?id=444&start=100

If it is implement:

We should report the move progress to user
Shutdown libtorrent correctly during a move. Currently the torrent state is corrupted.

Edit: New upstream issue is at https://github.com/arvidn/libtorrent/issues/2923 and stalled due to a technical obstacle described in https://github.com/arvidn/libtorrent/issues/2923#issuecomment-397900182

Originally created by @sledgehammer999 on GitHub (Mar 16, 2013). Tracking upstream bug: https://code.google.com/p/libtorrent/issues/detail?id=444&start=100 If it is implement: 1. We should report the move progress to user 2. Shutdown libtorrent correctly during a move. Currently the torrent state is corrupted. **Edit:** New upstream issue is at https://github.com/arvidn/libtorrent/issues/2923 and stalled due to a technical obstacle described in https://github.com/arvidn/libtorrent/issues/2923#issuecomment-397900182

deekerman added the

Feature request

Waiting upstream

Libtorrent

labels

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

deekerman commented

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

Author

Owner

@iheartcsharp commented on GitHub (Oct 25, 2021):

Until this feature gets added to libtorrent, there are two simple workarounds.

Since qBittorrent knows the torrent size, it can poll the new location every second and get the file size. Use the destination file size and divide by the torrent size. This would give you the progress. Not sure if this would work for all file systems so probably not the best option.
qBittorrent can do a copy using the system I/O. Once the copy is finished, update the torrent to the new path. Once it's been accepted, delete the original location. Basically a copy-on-write functionality.

Any thoughts on this? I think #2 would be more robust and easier.

@iheartcsharp commented on GitHub (Oct 25, 2021): Until this feature gets added to libtorrent, there are two simple workarounds. 1. Since qBittorrent knows the torrent size, it can poll the new location every second and get the file size. Use the destination file size and divide by the torrent size. This would give you the progress. Not sure if this would work for all file systems so probably not the best option. 2. qBittorrent can do a copy using the system I/O. Once the copy is finished, update the torrent to the new path. Once it's been accepted, delete the original location. Basically a copy-on-write functionality. Any thoughts on this? I think #2 would be more robust and easier.

deekerman commented

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

Author

Owner

@ericrosenberg1 commented on GitHub (Oct 28, 2022):

Would love to see this implemented

@ericrosenberg1 commented on GitHub (Oct 28, 2022): Would love to see this implemented

deekerman commented

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

Author

Owner

@bagobones commented on GitHub (Aug 14, 2023):

I download to a temp location them MOVE to a much slower network drive as rapid IO during download works much better on a fast local drive and a long continuous transfer tends to work well over network.

However moves are SLOW, VERY SLOW and the lack of progress is quite concerning on large transfers.

I would love to see a move progress bar of some kind or possibly a different move implementation as there are some other tickets that note using OS native file transfers can lead to much faster and reliable transfers in some cases.

@bagobones commented on GitHub (Aug 14, 2023): I download to a temp location them MOVE to a much slower network drive as rapid IO during download works much better on a fast local drive and a long continuous transfer tends to work well over network. However moves are SLOW, VERY SLOW and the lack of progress is quite concerning on large transfers. I would love to see a move progress bar of some kind or possibly a different move implementation as there are some other tickets that note using OS native file transfers can lead to much faster and reliable transfers in some cases.

deekerman commented

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

Author

Owner

@SeanVella commented on GitHub (Mar 27, 2024):

Bump this! We need it!

@SeanVella commented on GitHub (Mar 27, 2024): Bump this! We need it!

deekerman commented

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

Author

Owner

@alexx-ftw commented on GitHub (Mar 28, 2024):

Bump. This is a much needed QoL improvement

@alexx-ftw commented on GitHub (Mar 28, 2024): Bump. This is a much needed QoL improvement

deekerman commented

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

Author

Owner

@nathan815 commented on GitHub (Apr 3, 2024):

This would be great. It's been painfully slow to move files between docker volume mounts (on same physical drive), but showing the progress would make it a lot better.

@nathan815 commented on GitHub (Apr 3, 2024): This would be great. It's been painfully slow to move files between docker volume mounts (on same physical drive), but showing the progress would make it a lot better.

deekerman commented

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

Author

Owner

@phanirithvij commented on GitHub (Apr 8, 2024):

Please upvote the top post, more bump comments add nothing.

The new upstream issue is at https://github.com/arvidn/libtorrent/issues/2923 but it was closed by stale bot

@phanirithvij commented on GitHub (Apr 8, 2024): Please upvote the top post, more bump comments add nothing. The new upstream issue is at https://github.com/arvidn/libtorrent/issues/2923 but it was closed by stale bot

deekerman commented

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

Author

Owner

@mirddes commented on GitHub (Jun 16, 2024):

enabling implementation of some indication of file movement progression in downstream clients would be greatly appreciated.

@mirddes commented on GitHub (Jun 16, 2024): enabling implementation of some indication of file movement progression in downstream clients would be greatly appreciated.

deekerman commented

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

Author

Owner

@littlefisher666 commented on GitHub (Nov 27, 2024):

@littlefisher666 commented on GitHub (Nov 27, 2024): +1

deekerman commented

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

Author

Owner

@xavier2k6 commented on GitHub (May 23, 2025):

ANNOUNCEMENT!

For anybody coming across this "Feature Request" & would like/love to see a potential implementation in the future!
Here are some options available to you:

Please select/click the 👍 &/or ❤ reactions in the original/opening post of this ticket.
Please feel free (If you have the "skillset") to create a "Pull Request" implementing what's being requested in this ticket.
(new/existing contributors/developers are always welcome)

DO:

Provide constructive feedback.
Display how other projects implemented same/similar etc.

DO NOT:

Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s).
(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)

@xavier2k6 commented on GitHub (May 23, 2025): ## ANNOUNCEMENT! For anybody coming across this **_"Feature Request"_** & would like/love to see a potential implementation in the future! **Here are some options available to you:** 1. Please select/click the 👍 **&/or** ❤ `reactions` in the original/opening post of this ticket. 2. Please feel free _(If you have the "skillset")_ to create a **_"Pull Request"_** implementing what's being requested in this ticket. **_(new/existing contributors/developers are always welcome)_** ____ **DO:** * Provide constructive feedback. * Display how other projects implemented same/similar etc. **DO NOT:** * Add a "Bump", "me too", "2nd/3rd" etc. or "criticizing" comment(s). **(These will be disregarded/hidden as "spam/abuse/off-topic" etc. as they don't provide anything constructive.)**