Transfert not starting but sees peers

[resident]

Originaly posted here http://forum.utorrent.com/viewtopic.php?id=28415 but i can't manage to delete the post ..

I've been trying to develop a tracker on my own, but i'm stuck with the following problem :

When µtorrent (either 1.6.x or 1.7.x) gets the informations from the tracker (thru the announce url), it seems to parse the bencoded dictionnary properly, sees the first peer (which is a rtorrent - stock ubuntu install) BUT does not start downloading.

The problem seems to be caused by the fact that there's no data already downloaded by µtorrent.

Indeed, if before starting µtorrent i put one correct block of this torrent in the destination directory everything works fine !

This problem does not arise at all with azureus (windows/linux), or the official bit torrent client 5.x for windows.

Is there anything i can do to prevent this (possibly an option to check in µtorrent) ? Is this a known bug or a bug at all ?

Any help/advice will be appreciated !

Regards,

resident.

[Greg Hazel]

Well, if this was a know bug I imagine torrents would never start. It could be a rtorrent thing.

What does the logger tab say if you turn on all the logging?

[resident]

Well then explain me why Azureus & others manage to start ? (maybe that wasn't clear in my previous post : the source (the only seeder) is *always* a rtorrent client, and i've tried to download from it with several windows BT clients)

Anyway, here is my first test :

[14:29:22]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T
[14:29:22]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed
[14:30:27]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Disconnect: Connection closed
[14:31:21]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T
[14:31:21]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed
[14:32:26]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Disconnect: Connection closed
[14:33:05]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T
[14:33:05]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed
[14:34:10]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Disconnect: Connection closed
[14:35:07]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T
[14:35:07]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed
[14:36:12]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Disconnect: Connection closed
[14:36:44]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T
[14:36:44]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed <-- right after this i closed the torrent, downloaded manually a few pieces, and then reloaded the torrent
[14:38:03]  AAA.AAA.AAA.AAA  : Connecting: port 6991 source: T <-- connection following the reload : some pieces are localy available now.
[14:38:03]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Handshake completed
[14:38:03]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 3960
[14:38:04]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Sending 5 bytes of aggregated data
[14:38:21]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 1047
[14:38:23]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 3532
[14:38:37]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 3855
[14:38:44]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 598
[14:38:53]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 1506
[14:39:03]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 2560
[14:39:13]  AAA.AAA.AAA.AAA  : [libTorrent/0.10.4.0]: Send Have 90

It seems that if i do not re-check the content, the AAA.AAA.AAA.AAA peer is ignored all along the download, even if another peer shows up (like an azureus one) and the download process starts via this new peer (which manages to download from the AAA.AAA.AAA.AAA peer). I've yet to examine this more closely.

Also, please note that i found a bit odd that you do not let people re-check the content when there was nothing to check at the beginning .. we need to remove/readd the torrent in order to do this (in a nutshell : why have you taken the pain to prevent ppl from re-checking when there's alegedly nothing in the target directory, it can be useful !).

Regards,

resident.

PS : one quick and dirty hack i see right now is sending a message saying uTorrent has a piece (which it doesn't really have), and then request it later ...

[Firon]

Because the bug could be with rtorrent in regards to how it handles connections with µTorrent.

Also, stop the torrent to re-check.