Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4084 closed Bug (fixed)

after reaching seed state, no new peers are acquired

Reported by: gunzip Owned by: jordan
Priority: Normal Milestone:
Component: libtransmission Version: 2.22+
Severity: Major Keywords:
Cc:

Description

OS Linux Debian, transmission-daemon 2.22+ (12098)

on a private tracker (DHT/PEX disabled) things appear normal up to completion. however, in seed state, uploading continues only for those peers already connected and no more incomings are accepted. eventually, as those peers finish, no more uploading occurs at all ( 0 peers). for this reason i consider it unusable.

dropping back to the 2.21 release fixes the issue.

Change History (29)

comment:1 Changed 11 years ago by gunzip

just as an update, i've tried this with both utp enabled/disabled and result is same -- all new peers are rejected after reaching the seed state.

comment:2 Changed 11 years ago by jordan

gunzip, is this happening in trunk, or in the 2.2x branch, or both?

comment:3 Changed 11 years ago by gunzip

I believe it's happening in both.

I first noticed something was wrong about a week or so ago with one of the 2.21+ nightlies. After downloading and seeding overnight, the ratio on the torrent was only 0.20 and zero peers were connected. Normally i would have a ratio of 2 or 3, and would always have some peer activity. This behavior was repeatable, and was very uncharacteristic. Furthermore, rolling back to 2.21 things were OK again.

I thought the problem might be some quirk of the new utp feature i was trying, but disabling that didn't matter. Looking back over recent commits it's possible that ticket #4035 and r12022 might of had the opposite of the intended effect, but i can't follow the code to understand what is going on there. However the timing of that change does correspond to when things started heading south for me.

comment:4 follow-up: Changed 11 years ago by jordan

I'm not able to reproduce this behavior. I've tried out five torrents now and am able to seed in each of them.

First, to get the easy question out of the way, are you certain that this is an issue with Transmission, rather than the swarm? Is the S/L ratio low enough that you can expect Transmission to seed?

Second, does this behavior exist for you for torrents that are already seeds when you start them?

comment:5 in reply to: ↑ 4 Changed 11 years ago by gunzip

Replying to jordan:

First, to get the easy question out of the way, are you certain that this is an issue with Transmission, rather than the swarm? Is the S/L ratio low enough that you can expect Transmission to seed?

Yes i pretty much ruled out those side issues. I have both 2.21 and 2.22+ installed so i can switch between them in a matter of a minute.

Second, does this behavior exist for you for torrents that are already seeds when you start them?

Yes

I'm not able to reproduce this behavior. I've tried out five torrents now and am able to seed in each of them.

In your 5 tests...

were DHT and PEX disabled? I can seed too, but only to those peers that were already connected when i reached completion.

when you observed the swarm over the long haul, were you picking up new peers that were joining the swarm after you reached completion? That's my issue, after reaching seed state i get no new peers and the torrent eventually dies of inactivity.

Last edited 11 years ago by gunzip (previous) (diff)

comment:6 Changed 11 years ago by livings124

I'm definitely picking up new peers on a transfer I'm seeding. These peers are all from "incoming."

comment:7 Changed 11 years ago by gunzip

i'm going to try http://download.m0k.org/transmission/files/transmission-2.22.tar.xz (dated March 5) and see if there is a difference. that one has no utp build option .. will report back one way or the other.

comment:8 Changed 11 years ago by sardok

I'm seeing the same behavior as gunzip. Using Mac client, r12072.

comment:9 Changed 11 years ago by gunzip

ref: http://download.m0k.org/transmission/files/transmission-2.22.tar.xz

The above works fine and having no problem acquiring new peers after reaching seed state. I assume that is the next stable release? If so, looks good on my end.

Is it possible that building with utp support, regardless of whether it is enabled or not in settings.json, is causing the the problems in 2.22+ or is there something else going on.

comment:10 follow-up: Changed 11 years ago by jordan

gunzip, thanks for testing 2.22 on its own. It passing the test means a couple of important things:

  • Since it's only in the nightlies, we don't have to rush out a quick fix -- we can take the time to figure out the problem in depth.
  • The tickets that were backported from trunk to 2.22 like #4035 probably aren't causing the problem.

So the next question, since you're building from source -- could you find a svn revision in trunk that works? For example you say you noticed this about a week ago which puts us back around r12050. What about two weeks ago, at r12000?

comment:11 in reply to: ↑ 10 Changed 11 years ago by gunzip

Replying to jordan:

What about two weeks ago, at r12000?

OK, I've since did a svn checkout of r12000 with both the utp build and run options enabled, and the peer issue did not occur. The behavior is quite different from r12098 where the torrents kept dying out after reaching the seed state. Hopefully this might narrow down the problem a little.

BTW, on the TR download page "The current release version is 2.22" but the Source package still links to the old 2.21 tarball.

comment:12 follow-up: Changed 11 years ago by jordan

gunzip: would you be interested in trying out r12025? :)

comment:13 in reply to: ↑ 12 Changed 11 years ago by gunzip

Replying to jordan:

gunzip: would you be interested in trying out r12025? :)

$ ./trunk-r12025/daemon/transmission-daemon -V
transmission-daemon 2.21+ (12025)

the peer problem does occur here. so somewhere between 12000 and 12025 things head south.

comment:14 Changed 11 years ago by jordan

gunzip: would you be interested in trying out r12013? :)

comment:15 Changed 11 years ago by gunzip

the issue is not occurring in r12013

that leaves 12014 to 12025

Last edited 11 years ago by gunzip (previous) (diff)

comment:16 Changed 11 years ago by jordan

it's either r12019 or r12022 then...

comment:17 follow-up: Changed 11 years ago by jordan

gunzip, this is a shot in the dark, but does r12108 fix the problem?

comment:18 Changed 11 years ago by gunzip

Jordan, before i try another build please take a closer look at r12014 and r12015, especially r12015. from the description you are renaming functions:

torrentDestructor() to torrentDelete()

but in fact it's renamed to torrentFree

could this be the possible cause of the bug?

comment:19 Changed 11 years ago by livings124

gunzip: that just looks like a typo in the comments

comment:20 in reply to: ↑ 17 Changed 11 years ago by gunzip

Replying to jordan:

gunzip, this is a shot in the dark, but does r12108 fix the problem?

$ ./transmission-2.22+r12108/daemon/transmission-daemon -V
transmission-daemon 2.22+ (12108)

success! the problem is gone and transmission is sucking in the new peers again .. all back to normal.

so it looks like r12019 introduced the bug. after all this just curious to know, in layman's terms, what was going on here? also, i should probably test some more when i'm a partial seed to make sure that's not an issue. otherwise all looks good now.

comment:21 Changed 11 years ago by jordan

  • Status changed from new to assigned

Looks like there was a bug or missed assumption in tr_bitsetHasSet(). If that code had other uses I would go through it and debug it, but I'd rather use something more straightforward like r12110.

Thanks very much for helping track down this issue. You were able to trigger it faster than I was, so you probably sped this ticket up by several days. :)

comment:22 Changed 11 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed

fixed in r12108, r12109, and r12110

comment:23 Changed 11 years ago by sadface

About r12110, just point out that 'uploadOnly' is not set since r10500.

comment:24 Changed 11 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:25 Changed 11 years ago by jordan

oops.

Thanks sadface...

comment:26 Changed 11 years ago by jordan

jordan * r12112 libtransmission/peer-mgr.c: (trunk libT) #4084 "after reaching seed state, no new peers are acquired" -- possible fix.

This revises r12110 based on feedback from sadface about the use of tr_atom.uploadOnly.

comment:27 Changed 11 years ago by gunzip

everything still looks good with these latest revisions.

transmission-daemon 2.22+ (12114)

Last edited 11 years ago by gunzip (previous) (diff)

comment:28 Changed 11 years ago by jordan

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:29 Changed 11 years ago by jordan

  • Milestone None Set deleted
Note: See TracTickets for help on using tickets.