Add logic to verify there is an active connection

[phyzical]

hit google before a scrape to avoid removing items simply due to the fact the internet may be down

[ManiMatter]

Good idea, I see two problems here though.

decluttarr and qbit may not run on the same machine; with the proposed code, it would be decluttarr that tries hitting google and if failing, will cause qbit to skip. However, it may be that the machine that decluttarr is on is not connected to the internet, while qbit machine is; thus this logic would introduce false positives.

A second challenge I have is that just because google is reachable, it may still not be the case that qbit is connected.

Here is a proposal: Rather than hitting google from decluttarr, I would suggest that we check the connection status of qbit. https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-(qBittorrent-4.1)#get-global-transfer-info

If the status is "disconnected", then we skip.

Obv. this only works for qbit, but would already be an improvement and wouldn't come with the risk of false positives. Here would be my proposal, what do you think? https://github.com/ManiMatter/decluttarr/compare/dev...qBit-connection-test-prior-to-checking-for-slowness

[phyzical]

i think that would work for your case, my issue is i simply don't use qbit.

maybe we could instead use my check as a fallback if qbit url isn't provided?

[ManiMatter]

I would not want to introduce logic that could introduce problems to users (such as the ones I mentioned above).

Is switching to qbit an option for you?

[phyzical]

I think a non client specific solution/fallback would probably be better

we could just chuck it behind a "VERIFY_INTERNET_CONNECTION" flag and default to false?

[ManiMatter]

I'm not a fan of it;

1. I don't wan't to add more and more options to the tool, since it may start be confusing for users. Imo, this check should be done automatically, without the users even noticing (e.g. embedded in the slowness check code)
2. Just because decluttarr can successfully query google, it doesn't mean that the torrent client has access (different server that has no connection, or firewall issues, etc)
3. Just because decluttarr cannot query google sucessfully, it doesn't mean that the torrent client does not have access either (reverse of 2 - decluttarr may sit on a different server)

I'd prefer to use a logic where we check the connectivity of the torrent client, rather than decluttarr. For qbit - I think we have a proposal. For others, I see two ways: a) the queue response from the *arr apps add the torrent client connectivity status (would require a change on *arr side) b) decluttarr is enhanced to be able to query other torrent clients than "just" qbit (would require a significant change on decluttarr side)

On a), I don't think there is high chance, unless you contribute with a PR to them (have done it myself and it usually takes 2-3 months, but it gets done). On b), I won't have the time to do it, but please have a go ;)

Thus coming back to my initial question - any reason not to switch to qbit?

[phyzical]

a) the queue response from the *arr apps add the torrent client connectivity status (would require a change on *arr side)

id assume this too is dependent on client tbh

b) decluttarr is enhanced to be able to query other torrent clients than "just" qbit (would require a significant change on decluttarr side)

i may have a sniff around this, when i have time but will see

Thus coming back to my initial question - any reason not to switch to qbit?

Mostly lazyness/what ive got "works" 😆, but at the same time the more it leans towards "qbit only" the less it feels like a declutterarr and more of a qbit-declutterarr.

but I understand the points and do agree, i guess i'm looking from the lens all in one box and simply don't want a situation where.

• net dies
• declutter cleans and blacklists
• now manual intervention is required to be able to unblacklist to get those same torrents again

Ill leave this open for a bit and close if i dont find time to adjust support for multiple torrent clients

End of the day its an edge case and i suppose you will only loose 1 sweep of entries. And i can just have a forked image to fit my needs

[ManiMatter]

id assume this too is dependent on client tbh

Correct - but they do have code that can deal with the different torrent clients: https://github.com/Sonarr/Sonarr/tree/627b2a4289ecdd5558d37940624289708e01e10a/src/NzbDrone.Core/Download/Clients

[ManiMatter]

Closing since for qbit it is implemented and not planned (from my side) for other clients. Please create a new PR for any new contributions that may then support other torrent clients.