Download speed regression. 1.0.2 compare to 0.16.16 version.

[GoogleCodeExporter]

 We are using libtorrent in our application, a week ago we decided to update libtorrent from 0.16.16 to 1.0.2 version, but there is some problems. 
 if we select to download just first few pieces in torrent, torrent_handle::num_peers and num_seeds stays at value = 10. But old 0.16.16 version shows 50-60 peers/seeds with exactly the same selected pieces to dowload. When we select all pieces to download then seeds growing up to 50-60 as it should be. Can you help us to solve this issue, maybe we must change some settings or something else? 1.0.2 was builded with the same flags as 0.16.16.

Original issue reported on code.google.com by xcdix...@gmail.com on 19 Oct 2014 at 11:47

[GoogleCodeExporter]

Hello, 

We have the same problem  in our  torrent stream project.

If we need to download   few pieces(parties)  of file  when  use "torrent 
stream method" then peers are not going . 

But if we download standart method all is ok.

This is critical problem for streaming. Please fix it or tell us how to patch.

Original comment by erik.car...@gmail.com on 22 Oct 2014 at 6:52

[GoogleCodeExporter]

Is the problem that peers are disconnected when you think they shouldn't be? or 
is libtorrent just not connecting to as many peers? (the alerts you get should 
tell you).

could one of you provide logs, ideally logging=verbose 
(TORRENT_VERBOSE_LOGGING)?

what does "peers are not going" mean exactly?

Original comment by arvid.no...@gmail.com on 22 Oct 2014 at 7:29

[GoogleCodeExporter]

logs 0.16.18 - https://www.sendspace.com/file/ccfn8e
logs 1.0.2 - https://www.sendspace.com/file/tg0jk1

0.16.18 build flags: 

bjam --abbreviate-paths --without-python --disable-deprecated-functions 
toolset=gcc link=static boost=source variant=release dht-support=logging 
deprecated-functions=off logging=verbose upnp-logging=on -j 4 -d+2

1.0.2 build flags:

bjam --abbreviate-paths --without-python --disable-deprecated-functions 
toolset=gcc link=static boost=source variant=release dht=logging 
deprecated-functions=off logging=verbose upnp-logging=on -j 4 -d+2

both versions tested on http://rutracker.org/forum/viewtopic.php?t=4811562 
torrent. During test 1.0.2 shows 0 peers, 0.16.18 - about 20 peers at start.

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 9:48

[GoogleCodeExporter]

maget link for test torrent:
magnet:?xt=urn:btih:6667809878730F2B950B850324A9BF4306C0FE8C&dn=Poselentsy.2014.
WEBDLRip.by.%d0%94%d1%8f%d0%b4%d1%8f_%d0%9b%d1%91%d1%88%d0%b0.avi&tr=http%3a%2f%
2fbt2.rutracker.org%2fann%3fuk%3dwQK6UnqpJn&tr=http%3a%2f%2fretracker.local%2fan
nounce

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 9:55

[GoogleCodeExporter]

strange

0.16.18: libtorrent configuration: 
rel_performancetimer_pools_verboselog_resolvecountries_nodeprecate_dht_ext_

1.0.2: libtorrent configuration: performancetimer_nodeprecate_

but build flags are the same, maybe it's the problem?

Original comment by xcdix...@gmail.com on 24 Oct 2014 at 11:39

[GoogleCodeExporter]

that configuration symbol just capture ABI altering configuration options. I've 
been working on making the ABI more stable, and reduce the configuration 
options altering it (because this is a big source of usability problems).

I'll take a look at the logs and this torrent tonight, thanks!

Original comment by arvid.no...@gmail.com on 24 Oct 2014 at 5:31

[GoogleCodeExporter]

I can't really reproduce this. From your logs, it looks like all the IPs you 
get from the tracker fail to be connected to. when this happens, can you 
re-announce to the tracker, and does it still fail?

Does this problem happen reliably? and does it work reliably in 0.16.16?

Original comment by arvid.no...@gmail.com on 26 Oct 2014 at 7:21

[GoogleCodeExporter]

Does this problem happen reliably? yes, it does. Works fine in 0.16.16, but 
1.0.2 fails to connect. Maybe we are using some api that cause this 
disconnects, but 0.16.16 works fine.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:11

[GoogleCodeExporter]

tested on the same code, but different rasterbar versions.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:12

[GoogleCodeExporter]

0.16.18 works fine too.

Original comment by xcdix...@gmail.com on 27 Oct 2014 at 12:13

[GoogleCodeExporter]

If we look at peer 212.74.196.11#28873: new version disconnects with error_code 
'uninteresting upload-only peer', but old version continues to download. Same 
with other peers.

Original comment by xcdix...@gmail.com on 28 Oct 2014 at 3:49

[GoogleCodeExporter]

One more interesting thing. 0.16.18 version doesn't disconnects from peer if it 
sends to us 'have' responses with pieces that we don't interested in. 
Furthermore, 0.16.18 starts to download pieces from peers that wasn't send 
'have' message with that index. But new version just trust to 'have' responses 
and disconnects with 'uninteresting upload-only peer'. I think there is a main 
problem. You can clearly see it in my attached logs.

Original comment by xcdix...@gmail.com on 29 Oct 2014 at 7:19

[GoogleCodeExporter]

are you sure your piece or file priorities aren't set to 0? (i.e. not wanted). 
Or perhaps upload_mode is set to true?

when you add these torrents, do you have any resume data that may carry such 
state with it?

you can verify the state of the torrent by calling torrent_handle::status() and 
inspect the torrent_status object returned.

Original comment by arvid.no...@gmail.com on 30 Oct 2014 at 8:19

[GoogleCodeExporter]

yes, all pieces are set to 0. Just first 10 pieces selected to download. This 
case works fine in 0.16.18. upload_mode = false. Resume data is empty. 
torrent_handle::status() == downloading

Original comment by xcdix...@gmail.com on 30 Oct 2014 at 9:58

[GoogleCodeExporter]

Seems we have the same problem. Old version (before 1.0.0) connects to more 
numbers peers than new one (after 1.0.0) when torrent downloading partially 
(choosed only some chunks for downloading). I obtained the logs so it's the 
same problem libtorrent disconnets from peers with error 'uninteresting 
upload-only peer'. 

Original comment by drizt@land.ru on 7 Nov 2014 at 2:43

[GoogleCodeExporter]

thanks for the report! I've extended the priority unit test to cover the case 
in the logs and fixed the bug. The fix is commit [10475] in branches/RC_1_0 and 
will soon be in trunk as well. Please let me know if this does not fix the 
issue.

Original comment by arvid.no...@gmail.com on 9 Nov 2014 at 1:00

• Changed state: Fixed

[GoogleCodeExporter]

thank you, i will check it soon.

Original comment by xcdix...@gmail.com on 11 Nov 2014 at 1:19