Deluge not reporting hash-checks properly

Specific support for Deluge on Microsoft Windows OS
rhc
New User
New User
Posts: 2
Joined: Sat Apr 13, 2024 6:55 am

Re: Deluge not reporting hash-checks properly

Post by rhc »

ambipro wrote: Sat Apr 13, 2024 3:09 pm You could open a ticket and submit a PR on the github with this, it seems like a very minor change that could solve this problem (assuming it was an oversight) - worst case, we will find out if there's a reason and perhaps another solution will be proposed or something.
Thank you for your encouragement! I am busy the coming weeks, so I will stop here.

Anyone interested please feel free to try out this idea, and do the real work.


Here are some more thoughts.

1. According to libtorrent source session_handle.hpp, the only valid save_state_flags_t in libtorrent v2 are:

Code: Select all

save_settings
save_dht_settings
save_dht_state
save_extension_state
save_ip_filter

2. According to session_impl.cpp, the only flags used in save_state are:

Code: Select all

save_settings
save_dht_settings
save_dht_state
I am slightly surprised that ip_filter is not saved to session.state in deluge v2.x, but this is consistent with my very limited testing.


3. Thus, if 1 andd 2 are correct, the modifictaion becomes:

replace:

Code: Select all

_file.write(lt.bencode(self.session.save_state()))
with:

Code: Select all

state = self.session.save_state(flags=lt.save_state_flags_t.save_dht_state)
_file.write(lt.bencode(state))
This modification calls save_state() with flags, instead of modifying the resulting python dict. I was unable to figure out whether the python dict is considered internal implementation detail or not. Note that python-binding exposes flags in session.cpp. I can not find save_state_flags_t::all() exposed anywhere though.


Again, after modification, deluged starts and stops without error in debian 12. But I didn't do any futher testings.


4. In libtorrent v2, save_state/load_state have been depreciated. I have no idea how much work is required to rewrite using read_session_params/write_session_params.


P.S. Forgot that deluge 2.x supports libtorrent 1.2. Luckily, save_state() from libtorrent 1.2 seems the same as in libtorrent 2.0. So same modification might work in libtorrent 1.2 too.

Edit: I removed lt.save_state_flags_t.save_dht_settings from flags argument. Because ltconfig can modify dht settings, saving dht settings in session.state might result in 'stuck' dht settings.
Last edited by rhc on Sun Apr 14, 2024 1:38 pm, edited 1 time in total.
rhc
New User
New User
Posts: 2
Joined: Sat Apr 13, 2024 6:55 am

Re: Deluge not reporting hash-checks properly

Post by rhc »

TL;DR: I still believe my idea might work. But safe implementation might take more work than I expected.


My idea from my last two posts amounts to applying settings dynamically while libtorrent session is running. This process seems error prone, especially if/when order matters.


e.g. Deluge needs to set up network interface specified in core.conf *before* enabling dht. Else dht would start via libtorrent's default interface first. (Turn out that network interface is indeed set up first, even when session.state does not exist, because of the ordering of keys in preferencesmanager.DEFAULT_PREFS dictionary)


Similarly, say core.conf and ltconfig.conf both contain 'listen_interfaces' setting. User might expect that ltconfig.conf overrides core.conf in this case. But what actually happens when changes are applied dynamically one by one is slightly more subtle:

deluge will
Step 1. apply 'listen_interfaces' setting from core.conf first, then
Step 2. apply other core.conf settings which are not applied yet, and then finally
Step 3. apply 'listen_interfaces' specified in ltconfig.conf.

In particular, if 'enable_dht' is True in core.conf, dht would start during Step 2 via interface from core.conf, and only gets corrected to the interface specified in ltconfig.conf later during Step 3.


I guess the ideal solution would be to apply setting changes to session_pack object first before feeding the resulting session_pack obj into session constructor. But that would take quite a bit of work.
Last edited by rhc on Fri Apr 19, 2024 8:55 am, edited 2 times in total.
Post Reply