Opened 14 years ago
Closed 14 years ago
#842 closed Bug (invalid)
transfer speeds dropping to 0
Reported by: | Bollywood | Owned by: | |
---|---|---|---|
Priority: | High | Milestone: | None Set |
Component: | libtransmission | Version: | 1.11 |
Severity: | Normal | Keywords: | |
Cc: |
Description
using the nightly 1.11+ (5520) [happens with all versions back to 0.9], every time T makes a scheduled announce to the tracker, all torrent transfer rates drop to 0 until the announce has 'finished' ie... when starting a new torrent.
this doesnt seem to happen when using the manual 'update tracker' button...
Change History (11)
comment:1 Changed 14 years ago by livings124
- Milestone changed from 1.12 to None Set
comment:2 Changed 14 years ago by charles
- Resolution set to invalid
- Status changed from new to closed
I can't reproduce this. Methods I tried:
- adding a new torrent
- pausing + restarting a torrent
- watching the inspector's "tracker" tab and observing scheduled reannounce
I need more information on how to reproduce this before I can investigate it more. I'd close this as "needinfo" if trac had that option, but the closest match is "invalid"
comment:3 Changed 14 years ago by Bollywood
maybe its system dependent? It is definitely still happening on my system; 1GHz G4 iBook
a little more info: if you start/restart a torrent which hasn't previously had an announce during the current session it occurs. if the torrent has already had an announce, the error doesn't occur as exaggerated (ie speeds will drop, but not to zero)?
comment:4 follow-up: ↓ 5 Changed 14 years ago by Bollywood
- Resolution invalid deleted
- Status changed from closed to reopened
sorry if its not the right etiquette to reopen, but I wasn't sure on the reply protocol...
comment:5 in reply to: ↑ 4 Changed 14 years ago by Bollywood
Replying to Bollywood:
sorry if its not the right etiquette to reopen, but I wasn't sure on the reply protocol...
heres a screen capture: http://www.zippyvideos.com/4055526237529816/screenflow/
comment:6 Changed 14 years ago by charles
I haven't seen this behavior. However working from the theory that we're somehow overloading the router by sending out a scrape for too many torrents too close to one another, I've increased the randomization interval from 60 seconds to 120 seconds in svn trunk. Give that a try and see if it makes any difference.
comment:7 Changed 14 years ago by charles
- Component changed from Transmission to libtransmission
comment:8 Changed 14 years ago by Bollywood
this still seems to happen in the latest nightly: r5718
the bug is more pronounced on PirateBay? torrent files
comment:9 Changed 14 years ago by charles
I can't duplicate this.
comment:10 Changed 14 years ago by livings124
Here is the thread for this: http://forum.transmissionbt.com/viewtopic.php?t=2797
comment:11 Changed 14 years ago by charles
- Resolution set to invalid
- Status changed from reopened to closed
I *still* can't duplicate this. :(
I don't want this ticket to lie around in limbo forever, so I'm closing it for now. Please reopen this ticket if the behavior persists in the pre-1.40 nightly builds.
don't set milestones unless you plan to submit a fix