cfpp2p

[TRAC-4537](https://trac.transmissionbt.com/ticket/4537#comment:4)

Just compile the C library from https://github.com/maxmind/libmaxminddb Then a little work pseudo call and utilize: `mmdblookup --file [FILE PATH] --ip-file [FILE PATH]` https://raw.githubusercontent.com/maxmind/libmaxminddb/master/bin/mmdblookup.c Just a little tweaking of `lookup_from_file()` should...

This is a daemon threading problem that results from renaming a torrent while still in a magnet state. The rpc **method** when sent to the daemon has an immediate or...

@qu1ck It might be better if the existing pull https://github.com/transmission/transmission/pull/137 was utilized. It includes **server side download groups** https://github.com/transmission/transmission/pull/137/commits/bc8a56f56b9a0ab734d2f26149f17b20e57f43a6 with torrent set and get functions accessible through rpc **"downloadGroup"**. Already...

Here is a test patch being used by some transmission users: https://trac.transmissionbt.com/attachment/ticket/5002/RESENDS_MAX_COUNT.diff https://trac.transmissionbt.com/raw-attachment/ticket/5002/RESENDS_MAX_COUNT.diff and associated ideas: https://trac.transmissionbt.com/ticket/5002#comment:25

I see a couple of problems with proposed BitTorrent patch. The biggest issue is brought up by reardonia: > There is one edge case where nr can still be incremented...

patch to fix without throwing away data and whatever array size you want. https://gist.github.com/4199256#file_resends_max_count_v2.diff next I'll explain...

I don't see why to throw-away half the array at a time, especially when we don't really know if we'll fill it back up again. There are lots of reasons...

of course I have read the code properly, as far as "nr>=MAX" I was just keeping with the developer's (ghazel) style as per the developers submitted BitTorrent patches i.e. if...

> Could we confirm that this was fixed in 3652544? yes, fixed