qBittorrent process never ends #5097
Comments
|
It should exit after some time. |
|
I saw qBittorrent waiting for more than 10 minutes. It's too much. |
|
You should attach a debugger or add debug prints to see where it locks. |
I don't know how to do that in windows.
|
If you have MSVC2015 installed then you have WinDbg installed too. Choose the same 32/64 bit version as the qbittorrent binary(ignore OS).
This will give a backtrace of all threads. Usually the first one is the main thread. If your main thread is stuck how are you going to kill it? Spawn a different thread beforehand? |
|
Sorry I don't have any compiler in Windows.
I know it's really dirty but yes. |
|
If you can: |
|
I will next week. |
|
Here is a backtrace from Linux: |
|
The thread |
|
@evsh Congrats you just referenced a bunch of issues on github :p Next time wrap such content in triple backticks: |
|
Ups... Thanks for correcting the post! |
|
@sledgehammer999 |
|
The main problem for me is qBittorrent prevents the computer from shutting down. At least in Windows 10 after 1 or 2 minutes without being able to close the process, Windows cancels the shutdown and the computer stays on all night. |
|
On torrent count as high as 2k shutting down qbit is taking long time here too. I'd suggest writing fastresume data to one unified file instead of two thousand individual ones |
|
uTorrent does this inside of resume.dat |
In this case, we run the risk of losing all data when some failure. To avoid this, we must use a "protected" mechanism, such as SQLite database. But maintainer (@sledgehammer999) has fundamental objections to the use of such things in the qBittorrent. |
|
Why? Current system is very slow. |
|
I had the same problem on Linux for a long time, until I came across a forum post that helped me. Try removing extraneous trackers (anything over 2-3 is excessive). It seems that people get this idea that more trackers is automatically better and will add something like 30+, some of which no longer work but your client checks them anyway. Prior to this, my client would never seem to exit, and my patience did not extend past the 5-minute mark to see if it ever would. Now it takes less than 20 seconds, even though I have over a hundred torrents. Maybe a feature that prunes non-functional trackers after failing to connect X times would help with this. |
|
Not a really great solution, I'm sure lots of users need errored trackers. |
|
A lot of users need trackers that don't work? That's fine I guess, maybe something optional for others would be nice. I don't mind manually pruning, but many people are just going to end up frustrated and blame it on the client. |
|
@Rrak - Do you have automatic tracker adding list set up? Can you share with me you list of trackers? |
|
I don't. It's not that I favor any particular trackers. If anything, I tend to try and diversify which trackers my torrents use in order to reduce the load on the larger ones like openbittorrent or publicbt, which everyone seems to use. |
|
Except last time I checked those two where dead from some time now. Right now I only use those two: udp://tracker.coppersurfer.tk:6969/announce If you need a different one or you need more you can check out this guy. He prepears a lists of currently the best trackers and publishes the lists of them on his github. I asked him about what data he uses to prioritize trackers and uses
|
|
Is this being thought about? It's awful, shutting down the PC takes a minute longer because qBittorrent is "saving torrent progress" |
|
I believe proxy with socks5 protocol might be related. I've been using qBittorrent on Windows without proxy recently, and I've not had this problem. |
|
I am not using proxy in qbt settings and think i have never used. Yet the qbt process is shutting down several tens of minutes. |
|
It started happening to me with the update to 4.2.1 on Linux, had no problems before. |
|
I have my qBittorrent stuck since 32 hours, is there something I can do to help troubleshooting this bug? Maybe a core dump? |
|
I recognize that this is an old ticket, and probably has referred to different bugs over the years. However, I recently discovered (and fixed) an issue that could cause this in libtorrent 1.2.4 (fixed in the recent 1.2.5 release). here's the PR. |
|
@tuxayo if you have the ability, building libtorrent with |
|
I've had this/issue for the past week or so, since I started closing qbittorrent more often. I do not have anything useful in logs, and do not have a debugger/compiler setup The primary reason I'm shutting down qbittorrent is so I can switch between networks (because qbittorrent doesn't understand that I'm downloading to an NAS, and it's storage will disappear when I go offline), secondary so I can reset a router/update NAS. I currently have around 600 torrents either downloading, seeding, or queued. All of them are stored on my NAS. One of my torrents is >5000 jpg files, totaling ~2.6gb. I told qbittorrent to shut down about 3 hours ago For the past 30 minutes or so, qbittorrent has been opening and closing file handles from the torrent mentioned above, every 0.5-3 seconds, one at a time. (Information obtained from Process Hacker) Edit: qbittorrent has finally closed, about an hour after I noticed it was still open. |
|
Maybe it's because the network of qb is not closed? |
Interesting. @arvidn what could cause file handles to be closed so slowly? Do you think this might be a bug in the way qBittorrent saves .fastresumes, or could this be related to some bug in libtorrent's exit logic that causes those file handles to be held onto for a long time? |
This is incorrect. The handles were being opened and then immediately closed, in the space of 0.5-3 seconds each (mostly around once a second; me refresh rate is 0.5 seconds, so some of them could have been slightly less). The * I can't check now, because on upgrading 4.2.0 -> 4.2.2 earlier, it decided to move approximately 200gb of files located on a network drive, which will take a while to complete, and after which I will hopefully not have to move everything back |
|
Hi guys, is this bug fixed!?? Does qb quit the connection on the exit properly? Will it close the connection forcely if time is too long? |
Hello, this bug is still there. Nobody yet gave any information on an effective way to correct this bug. To answer your last question. No, there is no mechanism that will detect if the close process is "hanged" and then close it forcely. If the bug happens, it just hangs forever... |
Please update to 4.2.5 |
Ok, will do eventually, it's not an instant process for my setup. Do you say to update because you know for sure it's corrected, because you think it may be corrected and want to check if it works for me, or just because of a routine robotic procedure that you ask systematically to everyone like a tech support on the phone who asks to double-check if our router is plugged into the wall? I am asking this because I've been updating and updating and updating and the problem never left. I won't just update if you just suggest me this without having any good reason to think that 4.2.5 might correct the bug. Thanks |
I am saying it as even though this issue is quite old - if you were to open a new issue of your own for this, the latest version is a requirement. There have been many, many fixes not only on qBittorrent's side but also on the libraries used by qBittorrent. So, yes it may be fixed for you & possibly others in latest 4.2.5 & if not - I can provide a test build. |
|
Ok, will do so in the next days/week(s) and will come back here to report if bug still exists. Thanks! |
If not coming back for days/weeks - just make sure you install latest version available first as |
|
Don't use qb anymore. Just want to know is this bug fixed or not. |
Do you mean |
|
It's uploading data to other peer. Not the tracker problem. |
I don't remember the last time I had problems with that (on any client). Maybe try the latest version to see if it is still a problem? Bust out wireshark and do a packet capture (a bug in peer connections would most likely be a bug in libtorrent, not qBittorrent proper, anyway)? Otherwise, why comment here about something that's happened probably years ago, if you have no newer data to compare to? |
|
This issue stopped occurring for me a few months ago. |
|
I recently upgraded to the last version. I just closed qBittorrent for the first time after running for several days and it closed properly for the first time since forever. |
|
Closing this, due to reasoning based on the following comment (emphasis mine):
For all intents and purposes, this is now considered fixed. If experiencing similar symptoms in the latest version, they should be attributed to a potentially different underlying cause than what the OP and earlier comments were originally experiencing and referring to. For these reasons, it is better to close this issue report. It is better to keep reports focused, current and with relevant information, than to keep a very old thread filled with outdated information. If anyone has problems with the latest version, please open a new issue report, with all the required information, including settings and logs in plain text, and, if possible, follow the suggestion in this comment: #5097 (comment). You can also ask for test builds with the latest Thank you all for your contributions. |
and others
Windows 10 x64
qBittorrent 3.3.4
When I click FIle => Exit the tray icon disappears but the process is running forever... If I want to start qBittorrent again I have to kill the old process in the task manager.
When I shutdown the pc many times the pc never goes off because it's waiting for qBittorrent (the message is saving torrent...)
I don't know if it's caused by qBittorrent or by libtorrent but I think we should add a timeout (for example 5 seconds) and force exit if the task are not completed within that time.
@qbittorrent/qbittorrent-frequent-contributors
The text was updated successfully, but these errors were encountered: