I started a torrent which also contained 1 webseed. First there were some peers available so chunks were donloaded from there. After a while there were no seeders available anymore. The status of the webseed source was 'connected' at that time. Expected behaviour: KTorrent switches over to the webseed source when no seeders are available anymore. Actual behaviour: KTorrent doesn't switch over to the webseed but doesn't download anymore as there are no seeders available. Further details: The torrent I used was one from a HumbleBundle. I noticed that the seeders available were displayed as "0 (4)" so according to the tracker there were 4 seeders but KTorrent couldn't connect to any of those. But setting the seeders number to "0 (0)" through disabling the tracker also didn't cause the webseed being used, so the issue *isn't* caused by relying on the trackers seeder information for deciding whether to switch to a webseed. Enabling and disabling the webseed itself didn't fix the problem either. The same problem is described in bug 323125, but that is just a request for a workaround, not for fixing the real problem.
Git commit 03c1144efc5fc9ddfb7322defdc28153a4e010c2 by Harald Sitter. Committed on 13/08/2019 at 09:56. Pushed by sitter into branch '2.1'. unbreak http request Summary: there was a missing space before the HTTP version qualifier, missing a space there makes the request random garbage as far as the spec (and in fact most server impls) are concerned and result in broken webseeds as servers may respond with literally anything seeing as we've made a request with random garbage Test Plan: server starts responding to requests according to wireshark captures Reviewers: stikonas Reviewed By: stikonas Differential Revision: https://phabricator.kde.org/D23110 M +1 -1 src/download/httpconnection.cpp https://commits.kde.org/libktorrent/03c1144efc5fc9ddfb7322defdc28153a4e010c2
Git commit f50c7d660e64c3cf6ceff9ccdabf95ff62919256 by Harald Sitter. Committed on 13/08/2019 at 09:56. Pushed by sitter into branch '2.1'. fix streamsocket write-length calculation Summary: TrafficShapedSocket::write has a somewhat narrow contract with its caller. max may be 0 or >0, 0 meaning no limit, >0 meaning limit. this was incorrectly implemented before where we'd assume max means always limit, resulting in unlimited calls always resulting in 0 data getting sent as max would be 0. the revised code explicitly handles 0 meaning no limit. this is in line with the behavior of PacketSocket, the only other implementation of a shaped socket. Test Plan: webseeds start working by default and download at full bandwith Reviewers: stikonas Reviewed By: stikonas Differential Revision: https://phabricator.kde.org/D23111 M +3 -1 src/net/streamsocket.cpp https://commits.kde.org/libktorrent/f50c7d660e64c3cf6ceff9ccdabf95ff62919256