Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
WaterSibilantFalling opened this issue Oct 6, 2015 · 5 comments

Comments

@WaterSibilantFalling
Copy link

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.

@sledgehammer999
Copy link
Member

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.

@WaterSibilantFalling
Copy link
Author

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

@sledgehammer999
Copy link
Member

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
Copy link
Member

Any news on this?

@WaterSibilantFalling
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants