ManiMatter
Check global download speed and limits and skip slow download check conditionally
Hello!
I took it upon myself to try and implement my suggested feature. I followed the contributing.md, and all tests work. The feature works in my setup, and skips the check as youd expect in bandwidth limited scenarios.
Heres the feature request i opened.
#242
Please do tell me if i missed something, this is my first time contributing to an open source project!
It could be worth moving the check out of the for loop; if it does trigger then it will still be checked once, instead of once for each torrent. I will implement this change tomorrow.
Alright, i believe this version is good for merge.
I am unsure if stalled & downloading metadata torrents should be considered. I dont know if BitTorrent purposefully refuses metadata & seeders if download limit is met. The limit is somewhat regularly exceeded though, so i believe assuming that stalled & metadata downloads aren't adversely affected by download limits. They'd likely remain active until they reach a download state upon which they get throttled. I have experimented with pausing all torrents other than stalled & metadata downloading torrents, but i didnt see any reaction which would indicate that they were purposefully inactive.
I've seen download speeds at 30mbps when limits at 20mbps. I'm not sure exactly how qbittorrent works, but I'd assume the limit is very soft and will take what it can get but only ask for parts such that the speed limit isn't exceeded usually. With normal download speeds being so lax, I see no reason whatsoever why being at the download limit would hamper metadata downloads, provided you set the limit below your real world download limit.
hi Samsonsin,
many thanks for your initiative and creating this PR! Highly appreciated.
I've been working on a complete overhaul of the application (which took me way longer than I hoped), with the goal of making it more readable/maintainable, and support multi-instances (and some other improvements that people had asked for).
It's still in draft, and particularly the readme I still have to write (and I'm sure there's plenty of bugs). I will continue working on this, hopefully hardening it to a level where it's a good "v2".
If you'd like to help, and potentially add your refinement in there (and any other feedback/thoughts/contributions you'd like to share), I would very much appreciate it!
Branch is here: https://github.com/ManiMatter/decluttarr/tree/decluttarr-v2
Does that mean that you plan to depreciate the dev branch? My first thought would be that your changes in the v2 branch would be pulled to dev when finished. If so, i see no reason this pull request cant be pulled into dev? Do you want me to make a new pull request to the v2 branch, and close this one? Id be happy to help if you'd be clearer with what you need help with!
hey there! I had started off from dev, but at this point I have entirely written the thing, for which for now I left the dev branch untouched, and once the v2 is good for a beta release, I'll merge it to dev.
I don't plan to merge any other items to dev (which then I'd have to port to the v2). For v2, I will test more over the next days, and add readme on how to use it.
What would be tremendous are the following contributions:
- Maybe you spot any things in v2 you think can be done differently / better - happy to hear or any contributions welcome
- What you have already coded against dev - probably can be ported into v2 - that'd be awesome if you would contribute
So far, I've mainly tested v2 locally (ie. running main.py), I'll test the docker-setup over the next days as well. here, there's currently 2 ways how to run set the settings (either via docker-compose, or via .yaml file). I'll add that to the readme.
Just FYI, the code and readme of v2 is now in a state where it might not be 100% bugfree, but def. at a more stable state. Any feedback / code improvements (directly against the v2 branch), very apprecaite to receive it.
I'll have a look and see if I can implement this augment, then. When you say you're looking for feedback, do you mean general bugfixing, or architectural / methodology / code structure wise?
Edit: dude 4.5k additions and 3k deletions in 1 commit is nuts lmao
I'll have a look and see if I can implement this augment, then. When you say you're looking for feedback, do you mean general bugfixing, or architectural / methodology / code structure wise?
Edit: dude 4.5k additions and 3k deletions in 1 commit is nuts lmao
yeah.. i had so many back & forths that i finally simply squashed it all.. literally rewrote the whole thing.
i had started trying to make it more robust, easier to maintain, and support multiple instances of both the arr suite and qbit. i realize that i'm a bit out depth w.r.t my technical knowledge, and maybe certain things could have done better, simpler..
if you spot something that based on your experience could be simplified, very apprecaite if you have a go at it, or any pointers you can share with me.
As written in #242, this is now contained in v2. Thanks for this PR that helped writing it.
I will close this PR. Any future contributions in the form of PRs or issues to v2 are highly appreciated!