Libtorrent 2.0.8 update.

[ambipro]

torrents.state is the torrents, and I believe their stats and ****....the session.state should be the session itself between the daemon and the RPC and all the data and info its passing and storing in GTK maybe?

I'm not entirely sure of the specifics, but you need at the very least to transfer the entire state folder and IIRC it should load your torrents - granted you'll need to adjust queueing and all that stuff before everything seeds - but yea. It shouldn't be all that complicated to get those loaded into the client as they were at least.

I can't stress this enough. BACK IT UP SOMEWHERE BEFORE YOU DO ANYTHING - lol :D

[idiocracy]

So i did it, everything is back up and running. But i don't know yet if it did anything. I suppose it feels better, but that could be a placebo thing.
I kept the conf files for the plugins i was using, state & plugin folder. Then deleted the rest and started deluge up again. I changed the incoming port and tray icons. Rest just fell in line when i enabled the plugins.

[ambipro]

Yea it doesn't take very long to redo the base settings, and most of the time ltConfig is the only thing that can REALLY screw things up.

I'm more than willing to run through any settings you see that you don't understand - which are different in mine than yours - but mainly the aio threads is concerning and I'd be very surprised if you wouldn't see drastic improvements from going to at least 8.

[idiocracy]

There were some i noticed which i don't really understand. Looking them up and reading the description, but it's not always i understand the description.

max_peer_recv_buffer_size 5242880
send_not_sent_low_watermark 524288

The next thing i need to do is switch out the 2400G for a 5600G, i find i often hover around +90% load on core 1.

[ambipro]

that's suprising, but I guess it's possible...I never saw much in that range unless I was downloading at gbit speeds to spinning disks, when the IO queue was significantly lower with my SSD cache drive that went down to around 70%, but as I said that was on a 2600k

Those are just sizes of buffers, and assuming you have gbit-ish speeds when you are downloading could be beneficial - although not explicitly necessary.

Below is description from libtorrent docs, and then my attempt to laymen it out.

max_peer_recv_buffer_size - the max number of bytes a single peer connection's receive buffer is allowed to grow to (meaning that if you have a strong/fast connection with a peer, this is a much bigger buffer for it to read from, and since you are on SSD's for your downloads there would be no effective bottlenecking of the connection based on disk speed)

send_not_sent_low_watermark - specify the not-sent low watermark for socket send buffers. This corresponds to the, Linux-specific, TCP_NOTSENT_LOWAT TCP socket option. (this is linux specific, so it might not be relevant to you - but sets socket settings for libtorrent....i don't know how to really laymen terms this one tbh it can affect download and connection though)

[idiocracy]

When downloading at higher speeds, +90% appears to be normal. Deluge not responding either when downloading or having many torrents active also appears to be normal. At least on windows. I get the "not responding" more or less all the time and just have to wait for the UI to respond again, doesn't respond for 20 secs, then you get 5/10 where it is responding and then it's not responding for another 20 secs and so forth.
I can see on the network metrics that download/upload doesn't appear affected by the UI not responding.

[bengalih]

Hey guys. Since I'm luriking around for a bit figured I might go ahead and consider upgrading libtorrent versions.
Quite honestly I can't say I am having any specific issues with 1.2.15 that comes with 2.1.1 so I'm hoping someone will just spoon feed me here real quick as to if upgrading is recommended.
I'm sure there must be a reason for Deluge still shipping with 1.2.x when 2.0 releases were available, but I'm not sure why that decision was made.
Am I likely to experience more issues then benefits if I upgrade to a 2.x version and if upgrading is recommended is 2.0.7 the version to go to?

[ambipro]

I recommend 1.2.19, 2.0.x has many weird behaviors, especially on windows. Particularly with memory usage.

You can find a plugin for this behavior called wslimit in the plugins forum, but I still get much better performance off 1.2.x in my setup.

[greg2step]

Looking at the recommendation to roll back to 1.2.19 libtorrent, I think I am going to try

few quick questions is there a link the latest libtorrent pyd file download?

also, should I disable, remove, reset or do nothing with the ltconfig and wslimit plugins? I seem to remember ltconfig was to configure 2.0 and wslimit to prevent memory issues with 2.0 - do eithr have relevance w/ 1.2?

thanks in advance

Greg

[mhertz]

If you mean latest v1.2.x I.e v1.2.19(as you said), then if wanted is here: libtorrent-windows

Those are pre-built from pypi(as original installer also uses), just provided for easy access to not need manually find, download, extract and rename etc. If you ment latest v2.x, I.e v2.0.10(though guess not, considering rest of your post, just "newest" wording slightly ambiguous here), then not available on pypi because of an issue, but I built it for a friend recently and will add to that link later today(x64 only though), and currently only v2.0.9 there.

Disable wslimit if not using libtorrent v2.x anymore and yeah need add a conditional for that.

Ltconfig will mostly work fine, but just remember some options removed or added, so e.g if applied a preset(high-performance-seed etc), then might wanna reapply it, as only saves options available in the libtorrent session at the time.

Edit: Done(libtorent v2.0.10 added to top link I mean - it's btw for official installers, though also works for doadin's py3.9 installers, but not his py3.10 ones)