kannibalox

> Is this a bug or have I skipped a step somewhere? By default `--json` tries to output all fields, which includes a field that expects the custom command `d.session_file`....

> This throws an error. I tried a couple of different things in case I was missing some escaping, but I always get the same error: This is happening because...

I've documented the change in behavior and fixed the associated bug, closing this out.

Unfortunately I already develop against vanilla while porting changes into jesec/rtorrent for personal use, and for the sake of my own sanity I can't add in support for a fork...

Should be fixed now @stickz, let this be a lesson to me that no final little change is too small to thoroughly test.

I took a quick poke around the code and tried out a synthetic session with 10k UDP torrents, but didn't see anything immediately obvious. If you have profiles I wouldn't...

Do regular `rtcontrol` commands work in this state? As long as the SCGI socket/port is available and responding properly, it's unlikely to be a rtorrent bug.

Can you provide an example torrent? I just did a quick test, and rTorrent accepts pieces size up to 256MiB: ``` rtxmlrpc d.multicall2 '' main d.chunk_size= [268435456] ``` At 512MiB...

Currently the logic is "last tracker result wins", so if one tracker succeeds quickly, but the other takes a while to time out, you'll get an error message. I'm not...

It's possible to just script the whole affair, e.g. here's a basic python script using [pyrosimple](https://github.com/kannibalox/pyrosimple/) that disables all trackers that have only had failures: ```python import pyrosimple proxy =...