Opened 6 years ago
Closed 6 years ago
#1633 closed defect (fixed)
Snark gets stuck before download complete
Reported by: | zzz | Owned by: | zzz |
---|---|---|---|
Priority: | major | Milestone: | 0.9.22 |
Component: | apps/i2psnark | Version: | 0.9.21 |
Keywords: | Cc: | ||
Parent Tickets: | Sensitive: | no |
Description
All peers go uninteresting, even seeds, when a leech gets close to the end.
Have seen and fixed bugs like this before but it's back, possibly caused by bEP 6 changes in 0.9.21. Leech is not in end game yet, still ~40 pieces left.
Workaround: Stop and restart torrent.
Subtickets
Change History (4)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
Status: | new → accepted |
---|
See also http://zzz.i2p/topics/1930
Investigation started.
I believe that PeerState?.rejectMessage() needs to return the partial piece via PeerCoordinator?.savePartialPieces() when no requests remain outstanding for that piece.
If true this is a bug of omission. I don't see any issues in the code that was added, we just need some more code.
May be some complication in tracking what portion of the piece is doenloaded. TBD.
comment:3 Changed 6 years ago by
Status: | accepted → testing |
---|
Fix for this and several related issues, and fixes for bad data handling, in a95d5fd3f953820b2ad073a9ef12b26c0fc22137 0.9.21-2
comment:4 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | testing → closed |
<+dg> obscuratus: zzz speculated it was to do with the BEP 8(?) changes
< obscuratus> dg: I was sepeculating about the BEP 6 changes. When I revert the LPQ change, I didn't get a stall.
< obscuratus> I left the BEP 6 change intact.
< obscuratus> Bleh, s/I/zzz/
< obscuratus> dg: Anyhow, I'll leave it verbally for you also… Think LPQ (Linked Blocking Queue) in addition to the possiblity of the BEP 6 stuff.