Upload issues with recent RC_0_15 svn

[GoogleCodeExporter]

What steps will reproduce the problem?

Windows users are reporting upload problems since we updated to the RC_0_15 
branch (post v0.15.4). It seems there is no upload at all (or just one upload 
slot depending on the report). I ignored it at first (thinking of configuration 
issues) but I received 4 similar reports in the last 2 days (unlikely to be a 
coincidence).

It seems the issue appeared in qBittorrent v2.4.9.1 (last working version was 
v2.4.9). The only change between these two versions is that we updated from 
v0.15.4 to RC_0_15 branch (to get the "crash on loading empty torrent #122" fix 
iirc).

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
RC_0_15 branch on Windows XP or 7

Please provide any additional information below.
http://bugs.launchpad.net/qbittorrent/+bug/674867

Original issue reported on code.google.com by dch...@gmail.com on 16 Nov 2010 at 7:12

[GoogleCodeExporter]

do you know which version you're using?

Original comment by arvid.no...@gmail.com on 16 Nov 2010 at 3:54

[GoogleCodeExporter]

I know it was a revision just after you committed the "crash on loading empty 
torrent #122" fix. I am not the one packaging for Windows so I cannot know for 
sure what exact revision was used (I'll ask the packager though).

Original comment by dch...@gmail.com on 16 Nov 2010 at 3:59

[GoogleCodeExporter]

the problem is that there's only one upload slot, even though it's set to more 
than one?

what does the unchoke status in session_status return? specifically 
num_unchoked and allowed_upload_slots.

Original comment by arvid.no...@gmail.com on 16 Nov 2010 at 11:30

[GoogleCodeExporter]

The Windows packager said he used svn r4958 from RC_0_15 branch. This is all I 
know for now.

Original comment by dch...@gmail.com on 17 Nov 2010 at 5:21

[GoogleCodeExporter]

what do you set the number of upload slots to? did you enable or disable the 
dynamic upload slots?

Original comment by arvid.no...@gmail.com on 19 Nov 2010 at 5:15

[GoogleCodeExporter]

default is 4 (guessing the users did not change it). I did not know that 
dynamic upload slots existed (so whatever the default is).

Of course, this could be a configuration issue. However, since several users 
reported the same problem, I'm not so sure about it anymore. Is there is change 
in recent RC_0_15 branch that could affect upload?

Original comment by dch...@gmail.com on 19 Nov 2010 at 6:52

[GoogleCodeExporter]

so, just to be clear, the problem is that there's only one unchoked peer, and 
there are multiple interested peers, and the expected behavior is that more 
peers should be unchoked, because the setting sets a higher limit than 1 for 
unchoke/upload slots.

And this problem only happens on windows, for some reason.

Original comment by arvid.no...@gmail.com on 19 Nov 2010 at 7:48

[GoogleCodeExporter]

Really bad news. I have also packaged recent RC_0_15 on my Ubuntu PPA and now 
Ubuntu users are reporting the same problem!

See https://bugs.launchpad.net/bugs/677804

The issue seems to be that there is no upload at all (or sometimes very little 
according to some users).

Original comment by dch...@gmail.com on 20 Nov 2010 at 2:15

[GoogleCodeExporter]

"The issue seems to be that there is no upload at all". are you referring to 
upload slots?

Original comment by arvid.no...@gmail.com on 22 Nov 2010 at 6:57

• Changed title: Upload issues with recent RC_0_15 svn

[GoogleCodeExporter]

I don't experience any upload issues. peers are properly unchoked and uploaded 
to.

Original comment by arvid.no...@gmail.com on 22 Nov 2010 at 7:17

[GoogleCodeExporter]

I am now able to reproduce the issue.

If I set an upload rate limit at 50Kb/s, then it works fine (this is default in 
qBittorrent).

However, if you disable the upload limit (pass -1 to the 
set_upload_rate_limit()), then you get now upload at all (instead of unlimited 
upload).

Original comment by dch...@gmail.com on 28 Nov 2010 at 5:32

[GoogleCodeExporter]

I have just recompiled the exact same qBittorrent version against libtorrent 
v0.15.4 to make sure the problem is not in my code. I confirmed that v0.15.4 
works fine and that the bug was introduced in RC_0_15 after v0.15.4 release.

Original comment by dch...@gmail.com on 28 Nov 2010 at 5:40

[GoogleCodeExporter]

here is the verbose log.

Original comment by dch...@gmail.com on 28 Nov 2010 at 7:49

Attachments:

• libtorrent_logs6881.tar.gz

[GoogleCodeExporter]

New log, it started to upload this time.

Original comment by dch...@gmail.com on 28 Nov 2010 at 9:59

Attachments:

• libtorrent_logs6881b.tar.gz

[GoogleCodeExporter]

The first log files looks really suspicious. Some connections appear to be 
logged to the same file, and there are plenty of instances where HAVE_NONE and 
HAVE_ALL is sent, even though the torrent is not complete. I believe that 
there's something more fundamental going on there.

As for the second logs, things actually look quite normal. The reason why it 
took a while to start uploading appears to be that the first peers that connect 
are seeds (or at least finished)

do you think the logging itself might have made it work?
a lot of the peers have everything except for the last file, and they're not 
interested

I'm thinking that I may have introduced some ABI incompatibility, and if you're 
not linking statically against libtorrent, and not rebuilding qBittorrent with 
the latest libtorrent headers, link incompatibility issues might occur. When 
you build with logging, you rebuilt libtorrent and qBittorrent and you had to 
make sure they were both compatible since some function signatures had changed, 
and it wouldn't link otherwise.

I'll take a look to see if I can find any ABI breaking changes. If you can 
easily reproduce it, maybe you could try narrow down which libtorrent revision 
that broke it.

Original comment by arvid.no...@gmail.com on 29 Nov 2010 at 3:03

[GoogleCodeExporter]

As you may have heard, I had a session initialization problem in qBittorrent 
devel (that I used for getting the logging data). This is now fixed and the 
upload issue is still there (not surprising since it was reported with 
qBittorrent stable).

However, I generated again some logging data with this fixed version to make 
sure the logs are correct. Note that for these logs, I did not get any upload 
although I was connected to 0% peers.

I have exactly one (popular) torrent added to the session with progress at ~50%.

Original comment by dch...@gmail.com on 29 Nov 2010 at 5:20

Attachments:

• libtorrent_logs6881c.tar.gz

[GoogleCodeExporter]

Not a single peer in those logs is a downloader. They're all seeds.

These are the searches I made:

grep "<== HAVE_ALL" *.log
grep "<== HAVE_NONE" *.log
grep "<== BITFIELD" *.log

There are no peers that say HAVE_NONE, half of them say HAVE_ALL, half of them 
sat BITFIELD with every bit set, except for two peers which seems to have lazy 
bitfields turned on, they say a BITFIELD with some bits not set, and they are 
later filled in with HAVE messages.

Maybe the peers you saw with 0% progress were connections still attempting to 
connect.

You should look at the flags of the peer_info structure to make sure connecting 
and queued aren't set. There are a fairly large number of outgoing connection 
attempts that just timed out as well.

Original comment by arvid.no...@gmail.com on 30 Nov 2010 at 2:50

[GoogleCodeExporter]

I believe this was caused by session_impl::load_state() setting max_uploads() 
to 0 by default, this has been fixed. Please re-open if the problem persists.

Original comment by arvid.no...@gmail.com on 18 Dec 2010 at 11:31

• Changed state: Fixed

[GoogleCodeExporter]

Sorry to announce that this patch did not fix the upload issues.

Here is from qBittorrent bug tracker:
Yep, trouble comes back =( Cheat with upload limit working.
ii  libtorrent-rasterbar6                 0.15.4+svn.r5101-0ubuntu1~maverick    
                                       C++ bittorrent library by Rasterbar 
Software
ii  qbittorrent                           2.5.2-0ubuntu2~maverick               
                                       bittorrent client based on 
libtorrent-rasterbar with a Qt4 GUI

Original comment by dch...@gmail.com on 22 Dec 2010 at 8:49

[GoogleCodeExporter]

chris, you said qbittorrent uses save_state() and load_state() right? If so, 
could anyone experiencing this issue post their settings file as it is *before* 
working around the issue by setting an upload rate limit.

Original comment by arvid.no...@gmail.com on 23 Dec 2010 at 2:13

• Changed state: Accepted

[GoogleCodeExporter]

Issue 58 has been merged into this issue.

Original comment by arvid.no...@gmail.com on 23 Dec 2010 at 2:13

[GoogleCodeExporter]

As I mentioned in the qbittorrent ticket, there were some uninitialized 
variables that I fixed which _might_ have caused these symptoms. I'm getting 
ready to call this done and cut the 0.15.5 release. Unless I hear anything 
about it not working I will do that in a few days.

Original comment by arvid.no...@gmail.com on 29 Dec 2010 at 6:32

[GoogleCodeExporter]

Here is a message from the qBittorrent forums:
"Uploads are fine while downloading but once seeding only uploads peter out to 
zero if the upload limiting box is set. Clearing the limiter and limiting the 
upload rate elsewhere (Netlimiter) quickly brings uploads back to life. Seems 
that there is something up with the way you do the upload rate limiting rather 
than a simple bug."

The user has qBittorrent v2.6.3 and libtorrent v0.15.5 (final).

Original comment by dch...@gmail.com on 19 Jan 2011 at 7:38

[GoogleCodeExporter]

Is this still an issue?

Original comment by ar...@bittorrent.com on 7 Feb 2011 at 5:31

[GoogleCodeExporter]

I don't think so. I haven't heard about this recently.

Original comment by dch...@gmail.com on 7 Feb 2011 at 5:37

[GoogleCodeExporter]

Original comment by arvid.no...@gmail.com on 20 Apr 2011 at 4:37

• Changed state: Fixed