Add advanced options for piece control defaults

[lesderid]

Adds advanced options to change defaults for downloading first and last pieces first and for downloading pieces sequentially.

These options (particularly the sequential downloading one) are somewhat controversial, so I've added them to the advanced options.

FWIW IMO there is no reason these settings shouldn't exist. Either the options shouldn't exist at all, or people should be able to change the default values for them.

Closes #164.

[jagannatharjun]

These options will be removed after #12542 (most possibly)

[lesderid]

These options will be removed after #12542 (most possibly)

That does not seem to make much sense to me. These options are not exclusively for video files.

I'm also not sure that proposal is a good idea, it feels to me like it serves to solve a very specific issue with a considerable increase in code and complexity.

In any case, I think in general it's preferable that features are decided on based on their merits, instead of being dismissed because another proposal might replace them in the future.

[jagannatharjun]

That does not seem to make much sense to me.

It's up for discussion

I'm also not sure that proposal is a good idea, it feels to me like it serves to solve a very specific issue with a considerable increase in code and complexity.

IMO the major use case for sequential downloading is videos, #12542 is the correct way of doing it.

In any case, I think in general it's preferable that features are decided on based on their merits, instead of being dismissed because another proposal might replace them in the future.

the objections discussed in #164 still stands. This option is not good for torrent health and should be discouraged. This PR would make a lot of users have it on by default. (I didn't read #164 fully)

[lesderid]

IMO the major use case for sequential downloading is videos,

I agree that it's probably this most common use case, but that does not mean it is the only one.

#12542 is the correct way of doing it.

I disagree. I don't think the sole fact that HTTP supports Range requests is a sufficient reason to add a HTTP server to a torrent client. If one would arbitrarily add features of this size for every potential use case, the project would be completely unmaintainable. Disregarding that, I'm not sure if this is even the best way to implement such a feature, both conceptually and implementation-wise.

(I didn't read #164 fully)

IMHO commenting on issues when you're wilfully ignorant about their specifics isn't very welcoming to new contributors.

I'd like to keep further comments about this PR only.

[jagannatharjun]

I don't think the sole fact that HTTP supports Range requests is a sufficient reason to add a HTTP server to a torrent client If one would arbitrarily add features of this size for every potential use case, the project would be completely unmaintainable.

We already maintain an HTTP server implementation in form of Web UI. Range request helps to provide proper feedback which allows to prioritize pieces needed for video playback. Bear in mind "prioritizing" a piece is different than sequential downloading file.

I'm not sure if this is even the best way to implement such a feature, both conceptually and implementation-wise.

conceptually yes, implementation wise nope. That why the PR is in the draft and will most probably be closed in the future. I plan to implement this in steps starting with #14234

IMHO commenting on issues when you're wilfully ignorant about their specifics isn't very welcoming to new contributors.

I agree with it but with some knowledge of BitTorrent protocol, I stand with what was posted in the original post. This option is not good for torrent health and should be discouraged.

[FletcherD]

Just wanted to thank you for this. It took some wrangling to compile for Windows, but I did it and the result is just what I wanted.

[glassez]

@Chocobo1, what is your general opinion on it?
I ran my eyes through the code and see that it is not implemented correctly, but I do not want to dig deeper into it if I am not sure that it is generally approved.

[Chocobo1]

@Chocobo1, what is your general opinion on it?

No opinion. Although this idea has been shot down many times in the past.

[glassez]

Either the options shouldn't exist at all, or people should be able to change the default values for them.

I don't agree. Some options values (like these ones) are allowed to be changed as an exception, so we don't allow you to configure the default value for them.

Although this idea has been shot down many times in the past.

I'd rather reject it, too.

[lesderid]

I ran my eyes through the code and see that it is not implemented correctly, but I do not want to dig deeper into it if I am not sure that it is generally approved.

Would you mind summarising what's wrong with it if it's not too much trouble? I may want to contribute to the project in the future.

Either the options shouldn't exist at all, or people should be able to change the default values for them.

I don't agree. Some options values (like these ones) are allowed to be changed as an exception, so we don't allow you to configure the default value for them.

I agree that options shouldn't necessarily be configurable in the general case, but here there's a use case and users somewhat frequently request it.

Although this idea has been shot down many times in the past.

I'd rather reject it, too.

Fair enough!

[glassez]

Would you mind summarising what's wrong with it if it's not too much trouble?

The main thing is your defaults aren't really application defaults. They affect "Add new torrent dialog" only. The default values should affect torrents added in any possible way.