mirror of
https://github.com/Cleanuparr/Cleanuparr.git
synced 2026-06-14 21:19:31 -05:00
[BUG] Cleanuparr "stalled" and "download metadata" striking doesn't work with lidarr, but works for radarr #50
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @zandadoum on GitHub.
Before submitting a bug report, I have:
What is the behavior?
EDIT: found out it has nothing to do with amount of things in the queue, it seems like a cleanuparr+lidarr problem specifically. more info in the comments down below.
I had Cleanuparr connected to my Radarr for some days without problem.
But yesterday I connected it to my Lidarr and enabled Huntarr too.
this led to a lot of stuff added to my qbittorrent queue.
Initially Cleanuparr was working fine, but I now have 50 tems. 20 seeding / queued for seeding
5 downloading
and the rest are stalled or stuck with downloading metadata
these last ones have been sitting there for hours, and my Cleanuparr, which is set for scheduled every 5 minutes, doesn't do anything anymore.
i don't exactly know why, but i have a feeling it's because of the huge amount of qbittorreent items currently "queued" and maybe cleanuparr doesn't go through the list properly anymore?
Which operating system do you use?
Linux
What type of deployment do you use?
Docker container
Relevant log output
Anything else?
No response
@Flaminel commented on GitHub:
Enable verbose logging first and follow the logs. Do the logs say anything about the items you expect to receive strikes? Cleanuparr does not go through all items in your qbit instance when running the Queue Cleaner - it just goes through your Lidarr/Radarr's items and tries to find them in qbit. Please share more context after you've reviewed the logs.
@zandadoum commented on GitHub:
ok, so i enabled verbose and i also cleaned up the amount of queued stuff.
apparently cleanuparr is skipping all stuff stuck in "downloading metadata". at least for lidarr queued stuff.
verbose log shows 3 entries every time:
job: queuecleaner
job: queuecleaner
job: contentblocker
i use qbittorrent, both QB and cleanuppar latest version and "max strikes for downloading metadata" is set to 3
i think for sonarr and radarr it actually works, but i cant test it right now
@zandadoum commented on GitHub:
well i dont know what to tell you, thats all there is in the logs. you told me to turn on verbose, i did that and it still doesnt show much else. if you think it's my fault, a wrong setting or something, i am listening: what else can i try or check?
PS: it's clear that this is not about amount of stuff in the queue, should i change the original title of the post?
@Flaminel commented on GitHub:
Those logs seem kinda slim. Are those all logs shown that could lead us to the problem? If the items are skipped, it means something regarding their state does not meet any requirements for them to receive strikes.
@Flaminel commented on GitHub:
Are there no errors in the logs? Maybe your download client is unreachable? Do other functionalities work as intended?
No need to change the title yet.
@Flaminel commented on GitHub:
You have to look inside the log files in the
/configdirectory. Do stalled downloads get removed from Radarr?@zandadoum commented on GitHub:
i use docker compose
is image: ghcr.io/cleanuparr/cleanuparr:latest
enough or do i have to specify exact version?
whats the bash command to check version?
@Flaminel commented on GitHub:
Please update to
v2.0.13then try again and check the logs. I've added more logs to hopefully help us in debugging this issue.@zandadoum commented on GitHub:
i went to /config and will paste it here, not much additional info tho, shows basically the same than in the UI
i don't have a current "stalled" example, but i do for "downloading metadata"
EDIT: added a STALLED example at the bottom, it's radarr tho and works as intented. no lidarr examples available right now.
LIDARR EXAMPLE OF SKIPPING A FILE WITHOUT EXPLANATION, NOT WORKING AS EXPECTED
that file has been stuck in "downloading metadata" for 6h.
RADARR EXAMPLE OF STRIKING+SKIPPING A FILE WITH PROPER EXPLANATION, WORKING AS EXPECTED
i just added this as a test and deleted after:
EDIT:
RADARR EXAMPLE OF STRIKING+SKIPPING A -STALLED- FILE WITH PROPER EXPLANATION, WORKING AS EXPECTED
i added this as a test as it had few peers:
@zandadoum commented on GitHub:
no, nothing in the logs at all. it's completely ignoring stalled and metadata stuck items from lidarr, like the program didnt even have thos subroutines or like lidarr function was turned off (it isn't, the failed import part works just fine)
i am looking at the logs in the UI, maybe there's more or better logs elsewhere?
@Flaminel commented on GitHub:
As discussed on Discord, this issue was caused by using the
blampe/lidarr:latestinstead of the official Docker image. Cleanuparr's torrent protocol detection has been improved and this should now be fixed withv2.0.14.@zandadoum commented on GitHub:
allright, got an album sitting in queue "downloading metadata" for around 45min. now, lets see:
seems like nothing new compared to before. it sees the album, but doesnt process it at all.
@Flaminel commented on GitHub:
Just pull the
ghcr.io/cleanuparr/cleanuparr:latestimage again. The log files will show the version after the app started.@Flaminel commented on GitHub:
Would you mind joining the Discord server to discuss?