Open anonymous82 opened 6 years ago
@DanielSmedegaardBuus That's not the issue here. The drive is practically empty.
@Knocks I think you might writing in the wrong issue thread? Not sure what your problem is, but this thread is about torrents never completing. Cheers! :)
@DanielSmedegaardBuus This is the correct thread. 100% torrents are shown as stalled, because they are not actually 100% complete. See what I wrote two posts above.
If the torrent is not finished, it should not be displayed as 100 percent. I have a torrent that's 98.9 percent complete under content but 100 percent complete on the main screen (torrent list). This needs to be addressed.
+1 . It should not round up to 100% even when there is 1 byte still missing. The "rounding" needs to be intentionally set it to 99.99% (or 0.99) when the bytes & pieces count is not exactly the full requested size/count.
If only to avoid user confusion , but also GUI/software errors.
Same issue here, content was downloaded but stayed at "stalled". Checking the content's tab showed two files with missing data (worth about 30MB total).
Version: qbittorent-nox v4.1.5 (WebUI) from Debian buster repo OS: Debian 10 (buster) (Linux 5.11.17 kernel) Arch: AMD64
Maybe important to note that it's writing to a directory mounted over SMB through CIFS, not sure if any of the other commenters have a similar setup with a network share going on
@xavier2k6 Could you tag this OS: Linux as well?
Could you tag this OS: Linux as well?
Done.
@smiba commented on 2021. máj. 17. 15:28 CEST:
Same issue here, content was downloaded but stayed at "stalled". Checking the content's tab showed two files with missing data (worth about 30MB total).
Version: qbittorent-nox v4.1.5 (WebUI) from Debian buster repo
OS: Debian 10 (buster) (Linux 5.11.17 kernel)
Arch: AMD64Maybe important to note that it's writing to a directory mounted over SMB through CIFS, not sure if any of the other commenters have a similar setup with a network share going on
@xavier2k6 Could you tag this OS: Linux as well?
Have you tried using this build for a while: https://github.com/qbittorrent/qBittorrent/issues/14288#issuecomment-825227387 ? When I tested it I didn't get the kind of stall I usually get when running out of disk space.
Have you tried using this build for a while: #14288 (comment) ? When I tested it I didn't get the kind of stall I usually get when running out of disk space.
Interestingly enough I've updated to v4.2.5 from the debian bullseye repo (changing my apt sources from buster to bullseye in a naughty attempt) a few days ago and haven't run into this since. But maybe I've just been lucky though, haven't added that much in the meanwhile
I'll wait some more to verify if v4.2.5 has fixed it for me
Have you tried using this build for a while: #14288 (comment) ? When I tested it I didn't get the kind of stall I usually get when running out of disk space.
Interestingly enough I've updated to v4.2.5 from the debian bullseye repo (changing my apt sources from buster to bullseye in a naughty attempt) a few days ago and haven't run into this since. But maybe I've just been lucky though, haven't added that much in the meanwhile
I'll wait some more to verify if v4.2.5 has fixed it for me
Actually it just happened to me on 4.2.5 in Debian (Buster I believe; I self-built from source) ... but it seems to be only happening when I have 10 large downloads running simultaneously (and other I/O tasks such as checking, usenet, etc) ... aka as others have mentioned when disk I/O has a hard time keeping up.
I too am seeing this issue. nothing to do with space. based on the "randomness" of it, it appears that it's either bad data from a peer that's never resolved, or the "end game" mode is not implemented properly.
do you think if we program it to put the last pieces of torrent (not files but the torrent itself) to the highest priority does any differences to the outcome? if it works it definitely isn't the solution but we'll be able to diagnose
No, I've tracked it down to broken piece handling. I believe if the piece that comes in that is wasted (fails) it doesn't requeue it and leaves it as failed. The force recheck path resets all the flags, which is why that path resets it.
@arvidn I've written an impressive piece of software that resolves this located here: https://github.com/KyleSanderson/qbittorrent-bugfixer
It would be appreciated if this could be resolved in the library.
After updating to 4.4.2 every downloading torrent stalled at 100%. It completes only after Force recheck.
After updating to 4.4.2 every downloading torrent stalled at 100%. It completes only after Force recheck.
Met the same issue.
I use multiple torrent apps. install biglybt allocate the torrent then overwrite your stalled torrent files to biglybt's allocated files and right click on the torrent in library and click recheck. for now at least you'll have your download until the situation is resolved with qbit
Same issue 4.4.2
Same issue 4.4.2
yup same here. how is this still an issue 5 years later? lol
Same issue. 4.4.1 and 4.4.2 both tried.
I have the same issue with a large (73GiB) torrent. It shows 100% and Stalled but in the Content tab the progress keeps increasing with the disk usage at 100% (reading, not writing) and no network activity. Really weird. I'm still waiting for the progress bar to finish, but it's a lot slower than the actual download. It feels like it's rechecking? I have rechceck on download off though, and it displays Stalled, not re-checking.
On 4.4.0
EDIT: It finished and it now shows Seeding. Really weird and annoying. It took 2 hours approx.
No, I've tracked it down to broken piece handling. I believe if the piece that comes in that is wasted (fails) it doesn't requeue it and leaves it as failed. The force recheck path resets all the flags, which is why that path resets it.
@arvidn I've written an impressive piece of software that resolves this located here: https://github.com/KyleSanderson/qbittorrent-bugfixer
It would be appreciated if this could be resolved in the library.
@KyleSanderson
I just saw this now. What does this program do? At a cursory look it doesn't seem to have identified the problem, has it?
I recently found that the "Queued I/O jobs:" in View-Statistics has a large value (>2000) when qBittorrent has a stalled 100% job. Leave it overnight it will turn to seeding status. Don't know if this is the situation for all torrents that has a stalled 100%, but looks like this is the cause of my case.
I recently found that the "Queued I/O jobs:" in View-Statistics has a large value (>2000) when qBittorrent has a stalled 100% job. Leave it overnight it will turn to seeding status.
Wouldn't this just be because your storage can't keep up? When I used to run into this bug (I no longer do, or at least have been without this happening for over a year since I updated to 4.2.5. I'm on 4.4.3.1 nowadays though), they would never recover automatically no matter how long I waited.
I recently found that the "Queued I/O jobs:" in View-Statistics has a large value (>2000) when qBittorrent has a stalled 100% job. Leave it overnight it will turn to seeding status.
Wouldn't this just be because your storage can't keep up? When I used to run into this bug (I no longer do, or at least have been without this happening for over a year since I updated to 4.2.5. I'm on 4.4.3.1 nowadays though), they would never recover automatically no matter how long I waited.
Very likely. I run my NAS on the RPi 4B 8GB, together with USB external hard drive. So the performance is very low. If the stalled 100% used to persist on your server with no queued I/O, then the I/O issue should be a special cause just for my case.
My torrent downloaded at peak 70MB/s which is around the average write HDD speed so it could be that in my case, but when the torrent was stalled at 100% I viewed my HDD status and it was reading at around 2MB/s and not writing at all (unless it's not shown by Windows Task Manager).
Please provide the following information
qBittorrent version and Operating System
4.0.1 (64 bit) Windows 10 (10.0.1xxxx)
If on linux, libtorrent and Qt version
(type here)
What is the problem
When torrent download reaches 100%, it stalls instead of completing. Starting and stopping the torrent doesn't make any difference. It will only complete if I force it to recheck and rechecking takes awhile.
What is the expected behavior
It doesn't complete upon 100% like it used to. Problem only started when I upgraded to 4.0.1 from 3.x.x
Steps to reproduce
Run multiple torrents at the same time. When torrent reaches 100%, it doesn't complete. It just stays at stalled.
Extra info(if any)
Try to run with multiple torrents for higher chance of problems. 6 out of 7 torrents failed to complete for me. However if I run only 1 torrent, it "might" complete. (Some did, some didn't). I tried multiple batches of torrents to try and figure it out.