Open eduarrrd opened 3 weeks ago
Quick note, I actually ran with QT_LOGGING_RULES=*.debug=true
(and QT_LOGGING_RULES=*=true
for good measure) for a while now. Verified by checking /proc/<pid>/environ
. I could not get the message above (qDebug("Download failure ...
) to show up in the web log console, qBittorrent.log, or stdout/err despite observing this behavior.
Given the number of qDebugs present (https://sourcegraph.com/search?q=context%3Aglobal+r%3A%5Egithub%5C.com%2Fqbittorrent%2FqBittorrent%24+qDebug%28%22&patternType=keyword&sm=0&groupBy=path), I assume I didn't properly enable the logging as I'm seeing none of them which appears quite unlikely.
What's the correct way to enable the log messages?
qBittorrent & operating system versions
qBittorrent: v4.6.5 Web UI (64-bit) Operating system: Docker / linux Qt: 6.6.3 Libtorrent: 2.0.10.0
What is the problem?
When qBittorrent attempts to download a torrent from an RSS, a failure is silent and persistent. Instead, it should retry (possibly with exponential backoff) for a decent while.
Sub-issue 1, visibility: If I read the code correctly, the download error becomes available in
Net::DownloadHandlerImpl::processFinishedDownload()
:The logging for both success and failure only happens via
qDebug()
(without a category) meaning it only becomes observable viaQT_LOGGING_RULES="*.debug=true"
. Thus a failing download is just hidden by default. It does look like the receiver slot is actually doing much with the error either.Sub-issue 2: retries: I can't see any behavior nor anything in the logs (with unset QT_LOGGING_RULES) that, after a failure, a second try to download the items is attempted, even after hours.
grep -i retry src/base/net/download*
comes up empty.As a result of these, qBittorrent finds a new torrent, attempts to download it, and the torrent is never heard from again. Inspecting the log only leads to confusion (see snippet below).
Steps to reproduce
Additional context
No response
Log(s) & preferences file(s)