Go back to using libtorrent 1.2.x until qBittorrent 5.x #17545
Comments
|
qBt 4.4.x is still providing builds with RC1_2 so this is kinda invalid request. |
Mac and Linux users are pretty much stuck with 2.x and most Windows users have no idea that those builds are being offered, especially since those builds are mostly about testing qt6 |
|
And what's so magical about qBt 5.x that tells you it won't have problems with libt 2.x? It seems to me that you mean |
Nothing. It's just a milestone that would be good to delay libtorrent 2.x deployment in qBittorrent because it is still a long way out, giving the libtorrent dev more time to figure out what is going on with libtorrent 2.x
Not really. I think the qBittorrent 4.4.x series has been so problematic for users that it is worth considering going back to libtorrent 1.2.x since so many people are choosing to stick with 4.3.9 since that is the last version that doesn't stop responding on their system. |
|
A lot of people do not know about the existence of qbt 4.4.x with libtorrent 1.2.x, it's true |
I don't see how people don't know that.....it's on the main site! @Pentaphon You opened a discussion about us whittling down the issues.....now you've just gone & created a needless (IMO) ticket. What issues have you experienced personally with libtorrent 2.x as so far you've no ticket open with any issue related to it?? If you have experienced issues, have you tried to reproduce them with the latest qBittorrent master CI builds?? |
Because most people just go for the main download. Most people don't even know what qt6 is. You know that's true.
That's a completely separate issue, which people clearly agreed with me on, according to the votes I got. As for this ticket, I'll be glad to close it once its been given some consideration.
I don't need to open tickets about this issue because they are already open. I'm not trying to spam you guys considering we still have 2,300 issues open. This ticket is about suggesting that the project revert to the actively maintained 1.2.x until libtorrent solves their issues with 2.x Here's just a few of the tickets about the issues people have with libtorrent 2.x #16043
No because like many people I've went to 4.3.9. and I need my torrents to work. |
Also, as I've pointed out to you before the current
Or
|
Can make a postscript which libtorrent is used by the client? |
Knowing that, you should make a more explicit announcement saying "IF YOU WANT TO GO BACK TO LIBTORRENT 1.2.X PLEASE USE THE RC1.2 BUILDS"
Still the majority in the poll.
I clearly said issues so I am technically correct.
Going back to 1.2.x in the main downloads and letting only testers willing to use CI builds and other test builds should be enough to get those 2.x issues fixed. Many people are probably wondering why qBittorrent stops responding so much but they don't know about going to Github to file an issue. It would be better for the current userbase to continue using the 1.2.x builds than have to deal with 2.x builds. The issues with 4.4.x are probably leaving a bad taste in their mouths.
If they don't remain, where's the 4.4.4 release to show that?
That's probably public torrenters with almost no torrents in their client just casually downloading one thing at a time and then closing their client. There's still a lot of utorrent users out there who also do the same thing. Many of the people I know who seed hundreds or even thousands of torrents have complained about qBittorrent and I told them to go with 4.3.9 and their issues stopped. Some even moved to other clients in frustration.
I can't mess with my hundreds of torrents right now. I'll give it a shot when 4.4.4 comes out but I don't expect things to change until other users confirm. |
Who are these testers you're talking about? We don't have a paid staff. All we have is our community (including the developers themselves). So our testers are ordinary users who like qBittorrent, and who have a desire to help its development, and not just to blame developers. |
What exactly does the lack of a paid staff have to do with the simple decision to hold libtorrent 2.x back until a later date? You can do this with a single person's decision.
Guess what? The main problems of libtorrent 2.x are now in full display, affecting most of your users by you willingly using it in production releases. The actual main problem right now is that you guys are insisting on keeping libtorrent 2.x in your production releases instead of simply saying "hey 2.x doesn't work well for our users yet, let's go back to 1.2.x until our volunteer testers and the libtorrent devs can figure out whats going on with 2.x" I really think you should keep 2.x to a smaller part of the community because right now, it's only causing headaches for the main userbase. Do you realize how long it took for 1.x to become stable enough as it is now? Heck, you may have to wait for 2.1.x and then maybe 2.2.x before all the issues are ironed out. Clearly, 2.x needs more time to test and fix before it is unleashed to the public. It's time to reconsider whether this was actually a good idea or not and be willing to roll back libtorrent to 1.2.x if need be. |
|
If 2.0.x was not provided as main build then most of these issues would be in the dark still. I’m strictly against going back to 1.2.x. We should only go forward and drop 1_2 support soon as this is just cluttering the download page according to your statement above. |
Well they aren't in the dark anymore. It's ok to go back to 1.2.x temporarily for the sake of providing a stable experience for the majority of users while you keep a 2.x branch for people who are willing to test and patch 2.x I don't see the value in pushing forward with 2.x other than the sake of going forward. There's nothing shameful about a temporary rollback until testers and devs can figure out when 2.x is actually going to be ready for production releases. |
|
tbh I think the qt 5 to 6 is more problematic due to how qt themselves handled it. At the point they started moving over there a pretty good sense that qt 5.15 was done unless you paid for updates. There was no notion of there being a version past 5.15.2 at that point and even qt devs only wanted to help on the opensource qt6 version. Around the same time libtorrent made version RC_2_0 the main branch and was not so much interested in developing RC_1_2 other than backporting fixes and was I think commented towards qbittorrent making that the default version to be inline with their position. So this is not really qbittorrent's faults. Things moved around and they made reasonable choices considering. Now that we know qt 5.15 is getting LTS updates thanks to KDE there is a choice to do this, Make qt5/15 lts the main dep and focus on getting qbit 4.4/5 and libtorrent RC_2_0 in sync where it performs as consistently as people claim 4.3.9 _ qt5 + RC_1_2 does. Right now qt6 is draining the available resources where they need to be focused on qbit + libtorrent. That's just my outside opinion. QT6 is causing more problems than it solves right now. Otherwise think the devs made the right choices considering the circumstances, at the time. |
|
It’s not going to happen because going back to 1.2.x would mean loss of features related to hybrid and V2 torrents. And according to you most people are dumb and will not download secondary links. So if someone got accustomed with v2 or hybrid torrents and suddenly they stop working, the issue tracker will be full of nuisance. |
|
@summerqb also it's not taking into account @arvidn and where he wants to focus his resources when dealing with issues and patches that occur from using qbittorrent. If he wants to focus on RC_2_0 and backport critical fixes to RC_1_2 that's not really something qbittorrent has any control over. Though I recollect him saying something to that effect, I am not speaking on his behalf. He can clarify his position if required. |
You mean the features that nobody really needs or even uses yet? I have yet to see a massive demand for hybrid and V2 torrents and most clients in the wild still do not support them. For that reason, 2.x can wait while testers and devs work on it and users can simply use 1.2.x with qBit 4.4.x and 4.5.x until libtorrent 2.x has the major issues ironed out.
That's why its best to roll back now. The complaints out there are strictly about performance. If qBittorrent went back to 1.2.x, the community would breathe a sigh of relief. Nobody would be saying "hey where's my V2 torrents!" they would be saying "thank god the devs realized that 2.x isn't ready yet. Now my client isn't locking up on me anymore".
Another reason why qBittorrent should take advantage of the backporting and just use the backports while waiting for 2.x to be fixed by our community and the libtorrent community. |
|
@Pentaphon There is no need to go back.....we provide libtorrent 1.2.x builds in conjunction with libtorrent 2.x builds with the exception of linux/macOS as already pointed out....
You can use a portable profile to test it or even make a backup of your torrents.
How do you expect "Our community" to provide fixes if we don't release builds to test with???? No one is saying that libtorrent 2.x roll-out has gone smoothly but to be honest that is expected in any new release of software in it's early stages.... |
Well, at least the fact that the problems are analyzed for a much longer time, so that the decision you mentioned cannot be made as quickly as you want. And this is not a decision that is made by one person. |
That's exactly why you actually do need to go back since most of the Windows users are not using those builds and the Mac/Linux users are left out entirely.
I'll consider it.
I never said to not release builds to test with. I'm just saying that the production builds need to go back to libtorrent 1.2.x alongside test builds that have libtorrent 2.x but you guys are doing the exact opposite to the detriment of the userbase. I've never heard of testing being done with an entire userbase rather than a dedicated, smaller group of beta testers.
Sure it is. That person is the maintainer or co-maintainers if that exists in this project. |
|
There is a static build for libtorrent 1.2, which is only mentioned on the wiki. |
|
Those are nox (webui) builds only. I don't build the desktop version statically. |
|
I to have had to drop back to v4.3.9. I'm not sure what the reason is, but I had way too many issues with freezing, whole screen going blank, torrents constantly checking and going back to that version fixed it and it's stable. Been running for months now. |
Yep, I've seen people saying the same thing all over the web and some people here actually don't believe me me when I say it's happening to other people. |
|
You should try 4.4.4 before blabbering the same thing over again. |
|
Should we try RC 1.2 or default? |
There's already been 2 reports of freezing in the hours since 4.4.4 came out so I have a feeling it will be more of the same. At this point this project is just putting users through 8 months of very buggy releases and the only response has been "let's keep doing the same thing and expecting a different result"
Just use the 1.2 version or 4.3.9 until the project actually solves the major issues. |
|
I'm testing the 4.4.4 with 1.2 libtorrent. So far it seems stable, I'll report back in a few days to this thread if there are any bugs and I'll report back in a few days time if it's still working great |
|
For me, the culprit is either libtorrent v2 or the way qBt uses it. Because the version (4.4.4) with the old v1.2 doesn't suffer of this problem. But people should not forget that we don't use qBt the same way... so the problem may not occur for everyone. I think it's more than possible that the problem occurs because of the number of torrents we have and their state (seeding, downloading metadata...) or/and the contents of these torrents. I did a simple test. I started qBt lbt v2 with my network cable unplugged and the UI was responsive. As soon as I plugged the cable, the UI was gone... so it's definitively when some internal logic quicks in that the problem occurs. I wonder if the devs could do a debug build which could help find the problem? Indeed, only the GUIs (Qt and Web) seems to be dead when the problem occurs so there is probably a way to output to the log file some interesting things... But maybe there is a more subbtle problem. Indeed, because I have a lot of torrents, bot v2 and v1.2 qBt versions are slow to start (can take up to 30 minutes) and during this startup sequence, the GUI is also plain dead whereas the upload/download appears to work. uTorrent manages to have a usable GUI during the loading process, for example. Why qBt can't? When I had just a few torrents, qBt was starting blazing fast so I didn't discover this issue until I reached a critical number of torrents. |
|
For example, when playing with Process Hacker, I found out that libtorrent v2 seems to do some memory mapping to access files whereas libtorrent v1.2 doesn't. Maybe if you have torrents with thousands of small files, it creates some problem. When I navigated to the "Memory" tab of Process Hacker, it took ages to list all the memory uses: there was a load of mapped files from torrents. My qBt v2 process was using up to 8 gb of "private bytes" memory with MemoryWorkingSetLimit=1024 (default 512) so was probably swapping a lot of memory (I have a SSD). The v1.2 qBt just uses 1.3 gb... Or maybe thereis a memory leak somewhere....! Please note the Windows task manager doesn't report the "Private bytes" memory usage. When I used the process manager, it was always showing a very low memory usage. I think the process manager reports the "Private WS" value from the "Working set" "Memory" information from Process Hacker "Statistics" tab of a process. Which is the physical memory used and, because of the MemoryWorkingSetLimit config default value of 512, will always be low. Interesting read which explains that "Private Bytes" is more accurate than "Working Set" (displayed by task manager): https://stackoverflow.com/questions/1984186/what-is-private-bytes-virtual-bytes-working-set If it's indeed the problem, maybe qBt should be proactive in detecting the condition and avoid it. If it detects at some point that its process consumes too much swapped memory, maybe it can start to pause incriminated torrents. I mean, I would definitively prefer this to an unusable GUI. If so, a tab (or a new column) showing the torrent projected or real memory usage could help us. Saving the latest memory usage for each torrent may also help. Or, if libtorrents allows it, to switch back to the old style file access for high memory usage torrents... We don't even have a way to know how many files or folder a torrent has... this information is nowhere to be shown in the GUI: it could be in the "General" torrent tab. |
|
Right now my v1.2 qBt uses 3,568 file handles and 1.29 GB of memory (private bytes) and currently downloading at 40 MiB/s. |
|
libtorrent (and qbittorrent team) is already working on mmap compatibility issues and performance differences with the 1.2 version. |
|
@james58899 Thanks for the information. So we just have to wait for it to be part of qBt. |
|
After a few hours, qBt v1.2 reached its cruise number of 5 890 handles and still use 1.32 gb of memory. With v2, it was using 6 more gigabytes at that number of handles. |
|
So far 4.4.4 with 1.2 seems solid. I'll keep testing. |
|
Someone who are curious about the new artifact: screenshots: |
|
@brvphoenix Oh perfect! Thanks. I definitively think we should test it to help pinpoint the problem's cause. I will do that before the end of the week. |
|
@brvphoenix Because we don't do fresh installs, do we need to edit the qBittorrent.ini file before starting it? I see in @glassez commit that it seems this version allow to change the "DiskIOType" in the advanced settings to this new ""Multi-threaded file read/write". It seems it needs to be set to 3 in order for the new system to kicks in. Which value and in which group do we need to put it inside the ini file? |
Not necessary. I have made the |
|
Glad it finally happened for the good of the users. It was most definitely not just "perceived" though. @thalieht @summerqb @xavier2k6 next time, just listen to your users when many of them are having issues. They just want to torrent, not have to deal with a freezing client because you think it has to push forward no matter what. It's ok to slow down or even roll back an update to make sure your production releases are stable! And please, if libtorrent v2 is STILL not ready for 4.5.0 when it is ready for release, don't just force v2 back in there. Just keep going with v1 until v2 is actually stable. People don't care if we don't get v2 for 4.5, 4,6, 4.7, etc. They just want a stable client. Even if it takes another year or two before the libtorrent team makes v2 stable, just wait it out. We don't want to have to do this again. |
|
now that v5 is released, is there any reason not to default to libtorrent 2? eg when installing from winget |
Nope. libtorrent2 is still not ready to be made default. The libtorrent dev has still not released any major new versions to fix the issues with libtorrent2. |
and others
Suggestion
I think the project should go back to using libtorrent 2.x until qBittorrent 5.x
Use case
libtorrent 2.x is simply not ready for new versions of qBittorrent 4.x and many people are staying at 4.3.9 (last version with 1.2.x) because of this. I think the project should consider sticking with 1.2.x until qBittorrent 5.x to give libtorrent more time to work out the bugs. 2.x should only be used on test versions of qBittorrent until 5.x comes out.
Considering that libtorrent is still maintaining 1.2.x with releases such as https://github.com/arvidn/libtorrent/releases/tag/v1.2.17
It makes sense to continue with 1.2.x for production versions of qBittorrent 4.x until testers can figure out the issues with libtorrent 2.x
Extra info/examples/attachments
No response
The text was updated successfully, but these errors were encountered: