[bug] 3.3.0 beta: does not track, or look to see, that files have been downloaded #3157

New issue

Closed

opened 2026-02-21 16:36:54 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-21 16:36:54 -05:00

Owner

Originally created by @WaterSibilantFalling on GitHub (Oct 6, 2015).

~~jDownloader~~ [whoops, sorry] qBittorrent is now downloading this same torrent for the 3rd time (see # 24 below) into the same directory. It has already downloaded it twice.

Without a "always check on startup", and without the ability to track the status of its files, and without looking for completed files in the completed directory, this will always happen - it seems.

Originally created by @WaterSibilantFalling on GitHub (Oct 6, 2015). ~~jDownloader~~ [whoops, sorry] qBittorrent is now downloading this same torrent for the 3rd time (see # 24 below) into the same directory. It has already downloaded it twice. Without a "always check on startup", and without the ability to track the status of its files, and without looking for completed files in the completed directory, this will always happen - it seems.

deekerman closed this issue

2026-02-21 16:36:57 -05:00

deekerman commented

2026-02-21 16:37:00 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 6, 2015):

You are using jdownloader. How does qbittorrent fit in the picture?

PS: I deleted your file-tree. It isn't needed, and I don't want potential pirated stuff posted here.

@sledgehammer999 commented on GitHub (Oct 6, 2015): You are using jdownloader. How does qbittorrent fit in the picture? PS: I deleted your file-tree. It isn't needed, and I don't want potential pirated stuff posted here.

deekerman commented

2026-02-21 16:37:00 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Oct 6, 2015):

Sorry, a brain-slip, I typed the wrong thing: I meant qBittorrent

@WaterSibilantFalling commented on GitHub (Oct 6, 2015): Sorry, a brain-slip, I typed the wrong thing: I meant qBittorrent

deekerman commented

2026-02-21 16:37:00 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 6, 2015):

File->Exit and wait until the process disappears from the process list in task manager. Launch it again. If the problem persists, open the log (view->log) and locate the relevant entries about that particular torrent. Copy them here.

@sledgehammer999 commented on GitHub (Oct 6, 2015): `File->Exit` and wait until the process disappears from the process list in task manager. Launch it again. If the problem persists, open the log (view->log) and locate the relevant entries about that particular torrent. Copy them here.

deekerman commented

2026-02-21 16:37:00 -05:00

Author

Owner

@sledgehammer999 commented on GitHub (Oct 8, 2015):

Any news on this?

@sledgehammer999 commented on GitHub (Oct 8, 2015): Any news on this?

deekerman commented

2026-02-21 16:37:00 -05:00

Author

Owner

@WaterSibilantFalling commented on GitHub (Oct 11, 2015):

Yes, it just happened again, nothing in the logs - no log messages.

I have restarted after a system reboot and now qBittorrent is writing over the top of completed files - I can see this with fnotifystat and by the change in the file times and through the qBittorrent interface

It is not writing with the .qB! extention, although, just writing over the tops of existing, completed files. The save paths in the fastresume files are correct. These are paths to directories that are mounted with udev, so the underlying /dev/sdX changes every reboot. I had thought that this might be related, but the save paths are correct in the fastresume files, and always seem to be correct when viewed via the qBittorrent interface.

I am using 3.3.0 beta, with /usr/lib/libtorrent-rasterbar.so.8.0.0 on 4.1.0-2-rt-686-pae #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) i686 GNU/Linux

Question: if I always delete all of the ~/.local/share/data/qBittorrent/BT_backup/.fastresume files, will all the files then be rechecked upon startup? (or will I jus loose all my torrents from qBittorrent?) A recheck upon startup would be best, slow, but the answer.

@WaterSibilantFalling commented on GitHub (Oct 11, 2015): Yes, it just happened again, nothing in the logs - no log messages. I have restarted after a system reboot and now qBittorrent is writing over the top of completed files - I can see this with fnotifystat and by the change in the file times and through the qBittorrent interface It is not writing with the .qB! extention, although, just writing over the tops of existing, completed files. The save paths in the _fastresume_ files are correct. These are paths to directories that are mounted with udev, so the underlying /dev/sdX changes every reboot. I had thought that this might be related, but the save paths are correct in the fastresume files, and always seem to be correct when viewed via the qBittorrent interface. I am using 3.3.0 beta, with /usr/lib/libtorrent-rasterbar.so.8.0.0 on 4.1.0-2-rt-686-pae #1 SMP PREEMPT RT Debian 4.1.6-1 (2015-08-23) i686 GNU/Linux **Question**: if I always delete all of the ~/.local/share/data/qBittorrent/BT_backup/*.fastresume* files, will all the files then be rechecked upon startup? (or will I jus loose all my torrents from qBittorrent?) A recheck upon startup would be best, slow, but the answer.