Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
One of the issues that I came across when using autoremove-torrents, is that there is no way to measure the elapsed downloading time. This has been somewhat discussed in issue #87. Fortunately there is a solution for transmission at the moment. I don't know if this can be implemented with other download clients. They all have the "seeding_time" parameter, so they should have the downloading_time parameter too am I right?.
Why do we need downloading_time?. Well in my particular case I use autoremove-torrents to deleted stalled or slow torrents. Without the possibility of accurately measure time (last_activity starts in a very low value and create_time starts measuring when the torrent is added not when the torrent is downloading, so it's useless too), it's impossible to filter these torrents. With downloading_time I could specify a condition that is "downloading_time greater than 900 secs and average_downloadspeed lower than 512 kb/s" and all torrents that are slow or not downloading at all for more than 15 minutes would be removed.