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

qBittorrent not responding for 2-3 minutes at launch with a huge CPU load after updating 4.1.2 to 4.1.3 #9547

Closed
EU73RP3 opened this Issue Sep 19, 2018 · 51 comments

Comments

Projects
None yet
@EU73RP3

EU73RP3 commented Sep 19, 2018

Please provide the following information

qBittorrent version and Operating System

qBittorrent 4.1.3 x64
Windows 10 x64

What is the problem

qBittorent isn't responding at launch during like 2-3 minutes, with a huge CPU load (70-75% with an i7 4790k).
After that everything seems turning to normal behavior, but it happens at every launch.
Switching back to 4.1.2 solve the problem.

What is the expected behavior

qBittorrent 4.1.2 (and previous versions) starts immediately on my system.

@JamesG269

This comment has been minimized.

Show comment
Hide comment
@JamesG269

JamesG269 Sep 19, 2018

I also experienced this. Back on 4.1.2 too.

JamesG269 commented Sep 19, 2018

I also experienced this. Back on 4.1.2 too.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

So I'm not the only one. Thanks for the feedback.

EU73RP3 commented Sep 19, 2018

So I'm not the only one. Thanks for the feedback.

@EU73RP3 EU73RP3 changed the title from qBittorrent not responding for like a minute at launch with a huge CPU load after updating 4.1.2 to 4.1.3 to qBittorrent not responding for 2-3 minutes at launch with a huge CPU load after updating 4.1.2 to 4.1.3 Sep 19, 2018

@alexblhr

This comment has been minimized.

Show comment
Hide comment
@alexblhr

alexblhr commented Sep 19, 2018

Same

@RabidWolf

This comment has been minimized.

Show comment
Hide comment
@RabidWolf

RabidWolf Sep 19, 2018

Also reverted to 4.1.2 as it's doing the same.

RabidWolf commented Sep 19, 2018

Also reverted to 4.1.2 as it's doing the same.

@JamesG269

This comment has been minimized.

Show comment
Hide comment
@JamesG269

JamesG269 Sep 19, 2018

Do you guys also have a large amount of torrents? Don't know if it's related but I have about 200 torrents seeding, can't see why qbittorrent would need to do much processing on them though.

JamesG269 commented Sep 19, 2018

Do you guys also have a large amount of torrents? Don't know if it's related but I have about 200 torrents seeding, can't see why qbittorrent would need to do much processing on them though.

@RabidWolf

This comment has been minimized.

Show comment
Hide comment
@RabidWolf

RabidWolf Sep 19, 2018

I have a fair bit but even in 4.1.2 it only took a minute to get the gui up, whereas 4.1.3 I've left it for 10 minutes and its still not responding.

RabidWolf commented Sep 19, 2018

I have a fair bit but even in 4.1.2 it only took a minute to get the gui up, whereas 4.1.3 I've left it for 10 minutes and its still not responding.

@FranciscoPombal

This comment has been minimized.

Show comment
Hide comment
@FranciscoPombal

FranciscoPombal Sep 19, 2018

Contributor

Have you tried a clean install? See the contributing guidelines for information on how to do it. You will lose your transfer list though, so be sure to backup any data before deleting it. See if the clean install fixes the issue

Contributor

FranciscoPombal commented Sep 19, 2018

Have you tried a clean install? See the contributing guidelines for information on how to do it. You will lose your transfer list though, so be sure to backup any data before deleting it. See if the clean install fixes the issue

@adem4ik

This comment has been minimized.

Show comment
Hide comment
@adem4ik

adem4ik Sep 19, 2018

Contributor

I can't reproduce the issue on my Windows 10 x64. I have about 150 active torrents, but qB v4.1.3 starts usually as expected in a few seconds.

@EU73RP3 can you check the "Execution Log" (Menu - View - Log) if there are any critical or warning messages?

Contributor

adem4ik commented Sep 19, 2018

I can't reproduce the issue on my Windows 10 x64. I have about 150 active torrents, but qB v4.1.3 starts usually as expected in a few seconds.

@EU73RP3 can you check the "Execution Log" (Menu - View - Log) if there are any critical or warning messages?

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@JamesG269 : I have a pretty large amount of torrents (436), but like I said, no problem at all with 4.1.2. If adding torrents was the problem, I think I should have experienced the trouble only on first start, not after.

@FranciscoPombal : No I didn't, part of the charm of qBittorent is you usually don't have to do this when updating. Maybe I'll give it a try.

@adem4ik : nothing suspicious in the execution log I think, and no critical or warning.

EU73RP3 commented Sep 19, 2018

@JamesG269 : I have a pretty large amount of torrents (436), but like I said, no problem at all with 4.1.2. If adding torrents was the problem, I think I should have experienced the trouble only on first start, not after.

@FranciscoPombal : No I didn't, part of the charm of qBittorent is you usually don't have to do this when updating. Maybe I'll give it a try.

@adem4ik : nothing suspicious in the execution log I think, and no critical or warning.

@JamesG269

This comment has been minimized.

Show comment
Hide comment
@JamesG269

JamesG269 Sep 19, 2018

I think it's related to number of torrents, 4.1.3 must do extra processing on the torrents you have, or some kind of bug like that, over 4.1.2. I just uninstalled, checking options to remove config and torrents, and 4.1.3 started up, as soon as I restored the BT_Backup directory to \users\username\appdata\local\qbittorrent it started to not launch correctly again.

JamesG269 commented Sep 19, 2018

I think it's related to number of torrents, 4.1.3 must do extra processing on the torrents you have, or some kind of bug like that, over 4.1.2. I just uninstalled, checking options to remove config and torrents, and 4.1.3 started up, as soon as I restored the BT_Backup directory to \users\username\appdata\local\qbittorrent it started to not launch correctly again.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Sep 19, 2018

Hi Everyone!
I'm experiencing the same behavior with 4.1.3. , so I had to reverse back to 4.1.2. version. It has a huge bug! Please, fix this bug A.S.A.P. ! Thanks.

ghost commented Sep 19, 2018

Hi Everyone!
I'm experiencing the same behavior with 4.1.3. , so I had to reverse back to 4.1.2. version. It has a huge bug! Please, fix this bug A.S.A.P. ! Thanks.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@JamesG269 : Thanks for trying and for the feedback, don't have to try it myself.
So clean install doesn't solve anything, and the problem is related to the hudge amount of torrents to proceed.

Maybe 4.1.3 was only designed for casual seeders and hit and runners ;)

So seems we're stuck with 4.1.2 until a dev read this and solve it. Any idea about how to get rid of the update popup at launch until then ?

EU73RP3 commented Sep 19, 2018

@JamesG269 : Thanks for trying and for the feedback, don't have to try it myself.
So clean install doesn't solve anything, and the problem is related to the hudge amount of torrents to proceed.

Maybe 4.1.3 was only designed for casual seeders and hit and runners ;)

So seems we're stuck with 4.1.2 until a dev read this and solve it. Any idea about how to get rid of the update popup at launch until then ?

@RabidWolf

This comment has been minimized.

Show comment
Hide comment
@RabidWolf

RabidWolf Sep 19, 2018

Think I may have fixed mine by pausing all my downloads in 4.1.2 then installing 4.1.3. The gui opens in a minute.

RabidWolf commented Sep 19, 2018

Think I may have fixed mine by pausing all my downloads in 4.1.2 then installing 4.1.3. The gui opens in a minute.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@RabidWolf : Already tried, the same, and a minute to start each time ?! Common... With a Pentium III maybe it will be normal. I always had 300+ torrents seeding with all my clients since my first core 2, maybe my last P4, never had a client wich was not responding for a minute or more (maybe at the first start importing the list, but never after).

Is your qBittorrent window/task indicating "not responding" (or whatever it is in english - I use a french version of windows) during this minute it take to display the GUI ?

EU73RP3 commented Sep 19, 2018

@RabidWolf : Already tried, the same, and a minute to start each time ?! Common... With a Pentium III maybe it will be normal. I always had 300+ torrents seeding with all my clients since my first core 2, maybe my last P4, never had a client wich was not responding for a minute or more (maybe at the first start importing the list, but never after).

Is your qBittorrent window/task indicating "not responding" (or whatever it is in english - I use a french version of windows) during this minute it take to display the GUI ?

@djtj85

This comment has been minimized.

Show comment
Hide comment
@djtj85

djtj85 Sep 19, 2018

same here too...
win10 x64 qbit 4.1.3 with 6-700 torrent
i7-4790K CPU

djtj85 commented Sep 19, 2018

same here too...
win10 x64 qbit 4.1.3 with 6-700 torrent
i7-4790K CPU

@RabidWolf

This comment has been minimized.

Show comment
Hide comment
@RabidWolf

RabidWolf Sep 19, 2018

@RabidWolf : Already tried, the same, and a minute to start each time ?! Common... With a Pentium III maybe it will be normal. I always had 300+ torrents seeding with all my clients since my first core 2, maybe my last P4, never had a client wich was not responding for a minute or more (maybe at the first start importing the list, but never after).

Is your qBittorrent window indicating "not responding" (or whatever it is in english - I use a french version of windows) during this minute it take to display the GUI ?

BiB Yeah it still indicating "not responding" but the gui comes on after awhile. I agree its annoying even with a Ryzen 2700x. Something has definitely been changed in the code in 4.1.3 that has caused this.

RabidWolf commented Sep 19, 2018

@RabidWolf : Already tried, the same, and a minute to start each time ?! Common... With a Pentium III maybe it will be normal. I always had 300+ torrents seeding with all my clients since my first core 2, maybe my last P4, never had a client wich was not responding for a minute or more (maybe at the first start importing the list, but never after).

Is your qBittorrent window indicating "not responding" (or whatever it is in english - I use a french version of windows) during this minute it take to display the GUI ?

BiB Yeah it still indicating "not responding" but the gui comes on after awhile. I agree its annoying even with a Ryzen 2700x. Something has definitely been changed in the code in 4.1.3 that has caused this.

@CantThinkOfUserID

This comment has been minimized.

Show comment
Hide comment
@CantThinkOfUserID

CantThinkOfUserID Sep 19, 2018

I am also experiencing this issue, after updating to 4.1.3, but I only have 165 torrents and it took around 3-4 minutes to start compared to the usual 3-4 second start-up time. System is 4790K @4.4GHz, Windows 10 64-bit. While it wasn't responding the qbittorrent.exe process was at a constant 12.5% CPU usage, which on my CPU means 1/8 threads is being used to it's maximum speed, if qBittorrent is single threaded (Pretty sure it is) this basically means the program is using all the available CPU it's allowed to process something on startup that it didn't do in previous versions, not sure what it could be. This also happens every-time I launch the program and not just the first time after updating.

EDIT: The qBittorrent Install version is also 64-bit

CantThinkOfUserID commented Sep 19, 2018

I am also experiencing this issue, after updating to 4.1.3, but I only have 165 torrents and it took around 3-4 minutes to start compared to the usual 3-4 second start-up time. System is 4790K @4.4GHz, Windows 10 64-bit. While it wasn't responding the qbittorrent.exe process was at a constant 12.5% CPU usage, which on my CPU means 1/8 threads is being used to it's maximum speed, if qBittorrent is single threaded (Pretty sure it is) this basically means the program is using all the available CPU it's allowed to process something on startup that it didn't do in previous versions, not sure what it could be. This also happens every-time I launch the program and not just the first time after updating.

EDIT: The qBittorrent Install version is also 64-bit

@kisssandoradam

This comment has been minimized.

Show comment
Hide comment
@kisssandoradam

kisssandoradam Sep 19, 2018

same issue with lots of torrent (106)

kisssandoradam commented Sep 19, 2018

same issue with lots of torrent (106)

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@CantThinkOfUserID : Yep the process is at 12-13% here too, but the task reaches 60-75% of CPU usage in my case. Same, I7 4790k 4.4 Ghz. If it was uTorrent, I sould have suspected a mining operation lol ;)

EU73RP3 commented Sep 19, 2018

@CantThinkOfUserID : Yep the process is at 12-13% here too, but the task reaches 60-75% of CPU usage in my case. Same, I7 4790k 4.4 Ghz. If it was uTorrent, I sould have suspected a mining operation lol ;)

@CantThinkOfUserID

This comment has been minimized.

Show comment
Hide comment
@CantThinkOfUserID

CantThinkOfUserID Sep 19, 2018

@EU73RP3 Looks like the program is just getting stuck processing something in the new version, that it didn't before. I'm sort of O.K because i leave my computer for about 5 days at a time, but it's going to be a pain when it comes to having to launch the program again and waiting for 4 minutes.

CantThinkOfUserID commented Sep 19, 2018

@EU73RP3 Looks like the program is just getting stuck processing something in the new version, that it didn't before. I'm sort of O.K because i leave my computer for about 5 days at a time, but it's going to be a pain when it comes to having to launch the program again and waiting for 4 minutes.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 19, 2018

Contributor

I have a hunch on which is the offending commit. I have a naive(?) patch.
Can you test the following build? -> link (either replace the original files, or extract+run from another dir)
Patch:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index 441c0e576..fea37add7 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4035,6 +4035,8 @@ void Session::handleAlert(libt::alert *a)
 {
     try {
         switch (a->type()) {
+        case libt::piece_finished_alert::alert_type:
+            return;
         case libt::stats_alert::alert_type:
         case libt::file_renamed_alert::alert_type:
         case libt::file_completed_alert::alert_type:
Contributor

sledgehammer999 commented Sep 19, 2018

I have a hunch on which is the offending commit. I have a naive(?) patch.
Can you test the following build? -> link (either replace the original files, or extract+run from another dir)
Patch:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index 441c0e576..fea37add7 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4035,6 +4035,8 @@ void Session::handleAlert(libt::alert *a)
 {
     try {
         switch (a->type()) {
+        case libt::piece_finished_alert::alert_type:
+            return;
         case libt::stats_alert::alert_type:
         case libt::file_renamed_alert::alert_type:
         case libt::file_completed_alert::alert_type:
@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@sledgehammer999 : Nope, doesn't did the trick for me...

But thanks to study the question !

EU73RP3 commented Sep 19, 2018

@sledgehammer999 : Nope, doesn't did the trick for me...

But thanks to study the question !

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 19, 2018

Contributor

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

Contributor

sledgehammer999 commented Sep 19, 2018

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@sledgehammer999 : Yes !!! Perfect !

Do you plan to modify the installer or do we have to keep the patched version ?

EU73RP3 commented Sep 19, 2018

@sledgehammer999 : Yes !!! Perfect !

Do you plan to modify the installer or do we have to keep the patched version ?

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 19, 2018

Contributor

Do you plan to modify the installer or do we have to keep the patched version ?

Any fix to this will be included in a new release. You can keep using the patched version until then. But you run the risk of not having the benefit of that reverted commit. That commit fixes (temporarily) this issue: If you have forgotten to mount your disk where your torrent data lie (or in any way make them inaccessible) this commit will allow qbt to pause the relevant torrents with an appropriate error status, without continuing to download the data again and possibly overwrite the old files.

Contributor

sledgehammer999 commented Sep 19, 2018

Do you plan to modify the installer or do we have to keep the patched version ?

Any fix to this will be included in a new release. You can keep using the patched version until then. But you run the risk of not having the benefit of that reverted commit. That commit fixes (temporarily) this issue: If you have forgotten to mount your disk where your torrent data lie (or in any way make them inaccessible) this commit will allow qbt to pause the relevant torrents with an appropriate error status, without continuing to download the data again and possibly overwrite the old files.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 19, 2018

Contributor

@glassez @Chocobo1 @zeule from my tests the piece_finished_alert alert hugely dominates the queue in startup. As you can see above, I tried to early return the switch but that didn't help. Any thoughts/ideas on how to optimize it?
We apparently need progress_notification for file_completed_alert
Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

Contributor

sledgehammer999 commented Sep 19, 2018

@glassez @Chocobo1 @zeule from my tests the piece_finished_alert alert hugely dominates the queue in startup. As you can see above, I tried to early return the switch but that didn't help. Any thoughts/ideas on how to optimize it?
We apparently need progress_notification for file_completed_alert
Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 19, 2018

Contributor

Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

I mean, file a report to libtorrent to change their code.

Contributor

sledgehammer999 commented Sep 19, 2018

Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

I mean, file a report to libtorrent to change their code.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 19, 2018

@sledgehammer999 : Thanks, hope you'll find a solution solving both problems.

EU73RP3 commented Sep 19, 2018

@sledgehammer999 : Thanks, hope you'll find a solution solving both problems.

@alexblhr

This comment has been minimized.

Show comment
Hide comment
@alexblhr

alexblhr Sep 20, 2018

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

Can confirm this also works for me

alexblhr commented Sep 20, 2018

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

Can confirm this also works for me

@ltycomputer

This comment has been minimized.

Show comment
Hide comment
@ltycomputer

ltycomputer Sep 21, 2018

same

With 800 torrents,4.1.3 is non responding.

ltycomputer commented Sep 21, 2018

same

With 800 torrents,4.1.3 is non responding.

@TheOne320

This comment has been minimized.

Show comment
Hide comment
@TheOne320

TheOne320 Sep 21, 2018

Same. Windows 10 Pro x64 with qBittorrent 4.1.3

TheOne320 commented Sep 21, 2018

Same. Windows 10 Pro x64 with qBittorrent 4.1.3

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 21, 2018

Member

We apparently need progress_notification for file_completed_alert
Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

I think it makes libtorrent behavior to be inconsistent. It should either post all progress alerts or post none of them when checking fastresume data.
The one more thing that can be useful anyway is more precise alert filtering. Why should we overload the app, causing it to generate hundreds of piece_finished_alert if we only need file_completed_alert and torrent_finished_alert? But currently we can only filter them by alert class (e.g. progress_notification).
@arvidn?

@sledgehammer999, we can revert 2f90be8 but this issue shows the another problem. We can miss some important alert if we have short queue.

Member

glassez commented Sep 21, 2018

We apparently need progress_notification for file_completed_alert
Should we request libtorrent to not post piece_finished_alert when checking newly added torrents with fastresume?

I think it makes libtorrent behavior to be inconsistent. It should either post all progress alerts or post none of them when checking fastresume data.
The one more thing that can be useful anyway is more precise alert filtering. Why should we overload the app, causing it to generate hundreds of piece_finished_alert if we only need file_completed_alert and torrent_finished_alert? But currently we can only filter them by alert class (e.g. progress_notification).
@arvidn?

@sledgehammer999, we can revert 2f90be8 but this issue shows the another problem. We can miss some important alert if we have short queue.

@TheOne320

This comment has been minimized.

Show comment
Hide comment
@TheOne320

TheOne320 Sep 21, 2018

I tried the build posted here and it speeds up the start-up process, but it still hangs with a white screen for a few seconds.

TheOne320 commented Sep 21, 2018

I tried the build posted here and it speeds up the start-up process, but it still hangs with a white screen for a few seconds.

@arvidn

This comment has been minimized.

Show comment
Hide comment
@arvidn

arvidn Sep 21, 2018

@sledgehammer999 @glassez FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

arvidn commented Sep 21, 2018

@sledgehammer999 @glassez FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 21, 2018

Member

I tried the build posted here and it speeds up the start-up process, but it still hangs with a white screen for a few seconds.

As @sledgehammer999 said before:

from my tests the piece_finished_alert alert hugely dominates the queue in startup.

The posted build just have smaller alert queue so many of them is missed when the queue is overflowing. Of course it increases the startup speed but it can't be the valid solution.

Member

glassez commented Sep 21, 2018

I tried the build posted here and it speeds up the start-up process, but it still hangs with a white screen for a few seconds.

As @sledgehammer999 said before:

from my tests the piece_finished_alert alert hugely dominates the queue in startup.

The posted build just have smaller alert queue so many of them is missed when the queue is overflowing. Of course it increases the startup speed but it can't be the valid solution.

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 21, 2018

Member

FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

Looks good. But, IIRC, it will not be merged into RC_1_1?

Member

glassez commented Sep 21, 2018

FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

Looks good. But, IIRC, it will not be merged into RC_1_1?

@bhsgk

This comment has been minimized.

Show comment
Hide comment
@bhsgk

bhsgk Sep 21, 2018

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

I had the same issues as everyone else and this build fixed it for me.

bhsgk commented Sep 21, 2018

Can you try this 2nd build? -> link
It has commit 2f90be8 reverted.

I had the same issues as everyone else and this build fixed it for me.

@arvidn

This comment has been minimized.

Show comment
Hide comment
@arvidn

arvidn commented Sep 22, 2018

would this work? arvidn/libtorrent#3301

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 22, 2018

Member

would this work?

Looks good. Need to test it.

Member

glassez commented Sep 22, 2018

would this work?

Looks good. Need to test it.

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 22, 2018

Member

would this work? arvidn/libtorrent#3301

Yes, it works. Now we can filter out piece_finished_alerts!

Member

glassez commented Sep 22, 2018

would this work? arvidn/libtorrent#3301

Yes, it works. Now we can filter out piece_finished_alerts!

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 22, 2018

Member

FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

Just an idea for the further major update. Why not to make it filtered by each alert type? If you define alert types as power of two we will be able to filter them by each alert type as well as by alert class:

enum
{
    alert_type1 = 1,
    alert_type2 = 2,
    alert_type3 = 4,
    alert_class1 = alert_type1 | alert_type2 | alert_type3,
    alert_type4 = 8,
    alert_type5 = 16,
    alert_class2 = alert_type4 | alert_type5
};
Member

glassez commented Sep 22, 2018

FYI, in libtorrent master I've made this change: https://github.com/arvidn/libtorrent/pull/2894/files which I believe solves this problem.

Just an idea for the further major update. Why not to make it filtered by each alert type? If you define alert types as power of two we will be able to filter them by each alert type as well as by alert class:

enum
{
    alert_type1 = 1,
    alert_type2 = 2,
    alert_type3 = 4,
    alert_class1 = alert_type1 | alert_type2 | alert_type3,
    alert_type4 = 8,
    alert_type5 = 16,
    alert_class2 = alert_type4 | alert_type5
};
@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 22, 2018

Contributor

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z
Diff for qbt:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index 441c0e576..18f8fd924 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -392,7 +392,7 @@ Session::Session(QObject *parent)
                     | libt::alert::tracker_notification
                     | libt::alert::status_notification
                     | libt::alert::ip_block_notification
-                    | libt::alert::progress_notification
+                    | libt::alert::file_progress_notification
                     | libt::alert::stats_notification;
 
 #if LIBTORRENT_VERSION_NUM < 10100
Contributor

sledgehammer999 commented Sep 22, 2018

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z
Diff for qbt:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index 441c0e576..18f8fd924 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -392,7 +392,7 @@ Session::Session(QObject *parent)
                     | libt::alert::tracker_notification
                     | libt::alert::status_notification
                     | libt::alert::ip_block_notification
-                    | libt::alert::progress_notification
+                    | libt::alert::file_progress_notification
                     | libt::alert::stats_notification;
 
 #if LIBTORRENT_VERSION_NUM < 10100
@JamesG269

This comment has been minimized.

Show comment
Hide comment
@JamesG269

JamesG269 Sep 22, 2018

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z
Diff for qbt:

Tried it, start up normal, in like 2-3 secs with 200 large torrents seeded, downloaded ubuntu torrent and it completed correctly, will post if any issues come up.

JamesG269 commented Sep 22, 2018

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z
Diff for qbt:

Tried it, start up normal, in like 2-3 secs with 200 large torrents seeded, downloaded ubuntu torrent and it completed correctly, will post if any issues come up.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 22, 2018

Contributor

Question is now: How to incorporate these flags into our code until libtorrent does another release?
Remember that I build libtorrent from latest RC_1_1 commit when I do qbt releases.

Contributor

sledgehammer999 commented Sep 22, 2018

Question is now: How to incorporate these flags into our code until libtorrent does another release?
Remember that I build libtorrent from latest RC_1_1 commit when I do qbt releases.

@arvidn

This comment has been minimized.

Show comment
Hide comment
@arvidn

arvidn Sep 22, 2018

@glassez

Just an idea for the further major update. Why not to make it filtered by each alert type?

That would be a lot of flags. Currently there are about 90 different alerts, so the flags wouldn't fit in a 64 bit integer, which would make it difficult to fit that into the current settings_pack data structure.

arvidn commented Sep 22, 2018

@glassez

Just an idea for the further major update. Why not to make it filtered by each alert type?

That would be a lot of flags. Currently there are about 90 different alerts, so the flags wouldn't fit in a 64 bit integer, which would make it difficult to fit that into the current settings_pack data structure.

@THEtomaso

This comment has been minimized.

Show comment
Hide comment
@THEtomaso

THEtomaso Sep 23, 2018

I build libtorrent from latest RC_1_1 commit when I do qbt releases.

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

THEtomaso commented Sep 23, 2018

I build libtorrent from latest RC_1_1 commit when I do qbt releases.

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 23, 2018

Member

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

You want to wait even longer for the patches?

Member

glassez commented Sep 23, 2018

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

You want to wait even longer for the patches?

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 23, 2018

Member

That would be a lot of flags. Currently there are about 90 different alerts, so the flags wouldn't fit in a 64 bit integer, which would make it difficult to fit that into the current settings_pack data structure.

Well, then at least more precise filtering is welcome in the future update.

Member

glassez commented Sep 23, 2018

That would be a lot of flags. Currently there are about 90 different alerts, so the flags wouldn't fit in a 64 bit integer, which would make it difficult to fit that into the current settings_pack data structure.

Well, then at least more precise filtering is welcome in the future update.

@glassez

This comment has been minimized.

Show comment
Hide comment
@glassez

glassez Sep 23, 2018

Member

@sledgehammer999, one more thing that can increase startup performance (especially when there are many completed multifile torrents) is the fixing of handleFileCompletedAlert() described here.

Member

glassez commented Sep 23, 2018

@sledgehammer999, one more thing that can increase startup performance (especially when there are many completed multifile torrents) is the fixing of handleFileCompletedAlert() described here.

@sledgehammer999

This comment has been minimized.

Show comment
Hide comment
@sledgehammer999

sledgehammer999 Sep 23, 2018

Contributor

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

Yes, but specifically libtorrent git has important fixes/features that we should use. Some of the bugs are usually pointed out by us to be fixed.

Contributor

sledgehammer999 commented Sep 23, 2018

..which I've pointed out before; is NOT a god idea.
Stable software releases should use stable libraries, whenever possible!

Yes, but specifically libtorrent git has important fixes/features that we should use. Some of the bugs are usually pointed out by us to be fixed.

@EU73RP3

This comment has been minimized.

Show comment
Hide comment
@EU73RP3

EU73RP3 Sep 24, 2018

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z

Also got an immediate startup with 448 torrents seeding. Everything seems normal, but I don't use external storage for torrenting (so I never have mounted/unmounted/mounted drives used for my qBittorrent torrents paths).

EU73RP3 commented Sep 24, 2018

Can you guys try this new build based on the patched libtorrent? It is also based on vanilla v4.1.3.
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.3_x64_patched_for_issue_9547_v3_patched_libtorrent.7z

Also got an immediate startup with 448 torrents seeding. Everything seems normal, but I don't use external storage for torrenting (so I never have mounted/unmounted/mounted drives used for my qBittorrent torrents paths).

LordNyriox added a commit to LordNyriox/qBittorrent that referenced this issue Sep 28, 2018

sledgehammer999 added a commit to sledgehammer999/qBittorrent that referenced this issue Oct 1, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment