qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
28.34k stars 3.99k forks source link

Unable to complete torrent. Stays at "Stalled" status when 100% #7893

Open anonymous82 opened 6 years ago

anonymous82 commented 6 years ago

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.

Knocks commented 3 years ago

@DanielSmedegaardBuus That's not the issue here. The drive is practically empty.

DanielSmedegaardBuus commented 3 years ago

@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! :)

Knocks commented 3 years ago

@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.

rafi-d commented 3 years ago

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.

smiba commented 3 years ago

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?

xavier2k6 commented 3 years ago

Could you tag this OS: Linux as well?

Done.

mzso commented 3 years ago

@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: 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?

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.

smiba commented 3 years ago

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

ryusko2 commented 3 years ago

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.

KyleSanderson commented 2 years ago

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.

chauhansarthakiitd commented 2 years ago

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

KyleSanderson commented 2 years ago

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.

tarpaha commented 2 years ago

After updating to 4.4.2 every downloading torrent stalled at 100%. It completes only after Force recheck.

tan-wei commented 2 years ago

After updating to 4.4.2 every downloading torrent stalled at 100%. It completes only after Force recheck.

Met the same issue.

chauhansarthakiitd commented 2 years ago

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

JocPelletier commented 2 years ago

Same issue 4.4.2

greenbackz commented 2 years ago

Same issue 4.4.2

yup same here. how is this still an issue 5 years later? lol

Tianyuan-Wang commented 2 years ago

Same issue. 4.4.1 and 4.4.2 both tried.

z411 commented 2 years ago

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.

arvidn commented 2 years ago

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?

Tianyuan-Wang commented 2 years ago

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.

smiba commented 2 years ago

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.

Tianyuan-Wang commented 2 years ago

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.

z411 commented 2 years ago

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).