Arvid Norberg
Arvid Norberg
the `complete_sent` field is only set to true when receiving a tracker response where the request included `event=completed`
2 GiB is quite a lot for this disk buffer. Are you confident that increasing it would improve your disk performance? Are you sure you're not hitting your *random access*...
so, you want to download into RAM quickly, and then (slowly) write it out to disk, yeah? You won't be able to use the data while it's in the disk...
> I think something is wrong here. The step after thinking this is to find out the exact definition of the counters and then investigate "ground truth" and see how...
I don't understand what the bug report is. I think this is meant to be a bug report. There's a screenshot of a bunch of text and numbers. What's wrong...
this is a symptom of heap corruption. Does this reproduce consistently for you? Can you try running it under address sanitizer?
there are many reasons why this could happen. Do you manage to join the DHT? you can ask for the node count and the routing table. If you do, perhaps...
I believe this will fix it: https://github.com/arvidn/libtorrent/pull/7443
Do you know which object is leaking?
I strongly suspect that the memory being used is because of the (unbounded) number of calls to `read_piece()`. That call will cause libtorrent to allocate the size of one piece...