New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add: "Continuous download" and "Download first +last part first" #540
Conversation
In recent versions of mbed TLS, several symbols are moved to libmbedcrypto. Fixes: #115
This seems to be the idiomatic way to fix libressl compatibility issues, judging by what most other open source projects seem to be doing. I've confirmed that transmission builds with libressl for me after this patch is applied.
LibreSSL 2.7 adds OpenSSL 1.1 API See also: https://bugs.freebsd.org/226953 Signed-off-by: Bernard Spil <brnrd@FreeBSD.org>
Fix compile errors for 2.9x
It was always 0.0% as long as the torrent was not finished.
Field etaDLSpeedCalculatedAt was set too early, causing the condition following it to always be false. The same for etaULSpeedCalculatedAt.
Set the first version component to be the same as the last Subversion-based release build version and add two more components (major and minor version numbers). To allow for nightly build updates this should probably include another component (e.g. build timestamp), but we're not there yet.
Tracker error messages are inadequately output encoded when rendered by the tracker information page inside the WebUI, allowing a malicious tracker to inject an XSS payload into the page. Esploiting this issue allows an attacker to supply arbitrary client-side code that will ultimately be rendered and executed within the end user's web browser. Found by Rory McNamara (Gotham Digital Science). CVE pending.
This will prevent injection of arbitrary HTML when multiple torrents are selected. Follow-up to the previous commit.
@mikedld, I guess @mrbodich wanted to open an issue "Add: "Continuous download" and "Download first +last part first"", but instead opened a PR since I see no relevant commit here. Now people started to think, this feature is already implemented and closed the corresponding new issue #597. I'm wondering, how did it happen, that commits landed in this PR? And could you please rename the title to avoid confusion? |
All I did is merge 2.9x into master. If this empty PR was opened against 2.9x branch, maybe GitHub thinks that it's merged as well (despite it having no commits). What all the unrelated commits are doing here I have no clue. Might be easier to re-open #597 and mark this as invalid. |
On a side note, implementing this is unlikely to happen as it goes against the BitTorrent philosophy (e.g. see Sequential downloading is bad). |
Hello @mikedld. Thanks, have a nice day. |
"Sequential Downloads is bad" Oh okay but isn't it felt too forced to not include this PR, instead of just disabling it bydefault when merged. Even "webtorrent-cli" works the same way. And there are lots of users who use webtorrent to stream movies. The piece distribution is just a initiation problem. It'll never hinder any performance for longtime torrent health. |
I have to use qbittorent only because of these 2 features. I can start download video file from first and last part, make downloading continuous and watch a movie right when downloading was started, not wait till it ends.