Viktor Elofsson

Enabling UDP traffic to the SOCKS5 proxy makes libtorrent discover more uTP peers.  I assume the uTP connections are via the SOCKS5 proxy since there are `iptables` rules set...

I expose a simple `/metrics` endpoint with Boost.Beast and use Prometheus to pull metrics. The metrics are simply the session stats metrics from libtorrent formatted for Prometheus (ie. `key value`)....

I see! If patching, how would you want the gauges to work? Separate `num_socks5_tcp_peers` and `num_socks5_utp_peers`? And then keep the non-socks5 gauges for actual non-socks5 connections?

Seems like you're describing resume data, which [practically](https://github.com/qbittorrent/qBittorrent/blob/master/src/base/bittorrent/session.cpp#L4019) [every](https://github.com/picotorrent/picotorrent/blob/master/src/picotorrent/bittorrent/session.cpp#L766) [client](https://github.com/deluge-torrent/deluge/blob/master/deluge/core/torrentmanager.py#L475) [has](https://github.com/arvidn/libtorrent/blob/master/examples/client_test.cpp#L1402).

@master255 Care to show some code? So far all you've done is to confirm the behavior to be similar/equal to resume data. If it's a superior way of doing things...

@master255 I'm happy you linked to the exact message I wanted to quote. You say; >How my cache works: >When any torrent is removed from a session, add_torrent_params is serialized...

Hey! Thanks for the report - that clarifies things a bit! I'll do some more digging 😃

Thanks for the report! We should definitely handle this better.

I've found a torrent that provokes this behaviour so I'll see if I can put out a fix for this!

Hm - haven't seen that before... It's only the installed application and not the one from the zip file?