This is to allow re-checking of multiple torrents simultaneously. This will benefit users who
have multiple disks or SSD.
Closes#15296.
Co-authored-by: Chocobo1 <Chocobo1@users.noreply.github.com>
most of the time hash string is not needed and InfoHash is often used as
temporaries for torrent searching in handling of torrent alerts. This
improves the creation time of Infohash
This will allow users to perform action on all torrents with a single click instead of having to select all with ctrl+A or other cumbersome ways. Basically it copies the function found in tracker/category filters.
Closes#13398.
PR #16547.
Currently you can't directly change the priority of a partially completed multi file torrent. You'll have to start downloading those files and then change their priority.
Closes#10994.
Closes#8673.
PR #16546.
This improves readability and may allow users to match log message with
better accuracy.
Now log message is consisted of 2 parts:
The first part is a short sentence describing the event. It should avoid
writing out the specifics of the event as it will be described in the
next part of the message. The sentence should use correct tense of the
event.
The second part consist of `Name: Value` pairs which will provide
sufficient info for the event.
Note that none of the message parts is mandatory, one of them can be
omitted when the resulting log message is clear enough.
PR #16437.
This checks that `category_list[categoryHash].torrents` is truthy before dereferencing it. In some cases the API response will have a torrent in a category that doesn't exist resulting in the check to return `undefined` which is not `null`. This broadens the check so that it will create the category even if null.
PR #16432.
Speedup access to file priorities by avoiding extra blocking call to libtorrent thread.
Improve the Torrent interface by hiding the asynchrony of file priority changes behind the scenes.
PR #16425.
Chocobo1