mirror of
https://github.com/Cleanuparr/Cleanuparr.git
synced 2026-02-05 05:33:35 -06:00
[BUG] failed to clean Sonarr instance | http://192.168.4.204:8989/ #119
Loading…
x
Reference in New Issue
Block a user
No description provided.
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 @jgeorge1983 on GitHub.
Before submitting a bug report, I have:
What is the behavior?
Hi,
I have just stumbled accross an issue, I run cleanuperr from docker on a pi and connect to radarr/sonarr/lidarr which is running on docker on a synology NAS.
from the log I see:
My docker compose for cleanupper hasnt change, I've not changed my API key at all. at all. But I run:
image: ghcr.io/flmorg/cleanuperr:latest
I did upgrade my Sonarr on my Synology, but that is also running
image: linuxserver/sonarr:latest
I had a quick look through open/closed cases but couldnt see anything, i wonder if the latest sonarr has something different in it?
Which operating system do you use?
Raspberry Pi(cleanuperr), Synology NAS(sonarr/radarr)
What type of deployment do you use?
Docker container
Relevant log output
Anything else?
No response
@jgeorge1983 commented on GitHub:
I am using image: lscr.io/linuxserver/qbittorrent:latest
my docker for cleanupper is
cleanuperr:
depends_on:
gluetun:
condition: service_healthy
image: ghcr.io/flmorg/cleanuperr:latest
container_name: cleanuperr
environment:
- TRIGGERS__QUEUECLEANER=0 0/5 * * * ?
- CONTENTBLOCKER__ENABLED=true
- CONTENTBLOCKER__BLACKLIST__ENABLED=true
- CONTENTBLOCKER__BLACKLIST__PATH=https://raw.githubusercontent.com/flmorg/cleanuperr/refs/heads/main/blacklist
- DOWNLOAD_CLIENT=qBittorrent
- QUEUECLEANER__STALLED_MAX_STRIKES=3
- QBITTORRENT__URL=http://192.168.5.15:8082
- QBITTORRENT__USERNAME=
- QBITTORRENT__PASSWORD=
- SONARR__ENABLED=true
- SONARR__BLOCK__TYPE=blacklist
- SONARR__INSTANCES__0__URL=http://192.168.4.204:8989
- SONARR__INSTANCES__0__APIKEY=
- RADARR__ENABLED=true
- RADARR__BLOCK__TYPE=blacklist
- RADARR__INSTANCES__0__URL=http://192.168.4.204:7878
- RADARR__INSTANCES__0__APIKEY=
- LIDARR__ENABLED=true
- LIDARR__BLOCK__TYPE=blacklist
- LIDARR__INSTANCES__0__URL=http://192.168.4.204:8686
- LIDARR__INSTANCES__0__APIKEY=
volumes:
- /home/pi/docker/vpn-apps/cleanuperr/appdata:/config
Sonarr/Radarr don't need the password to connect to qbt
@Flaminel commented on GitHub:
What Docker image are you using for qBit? I'll need to test it. As for bypassing, how does your cleanuperr configuration look like?
@jgeorge1983 commented on GitHub:
Sorry, I was fast asleep when you posted this.
qBitTorrent set up hasnt changed at all, I can still connect to it from Sonarr when I test it.
I had it set to bypass authentication on certain subnets, and I have just set it to bypass for clients on localhost in case that makes any difference.
But no, i'm on version 5.0.4 of qbt, I dont remember upgrading, but i have a 6 month old, so i dont remember a lot at the moment.
@Flaminel commented on GitHub:
Hi!
The logs say it's a qBit problem, not a Sonarr problem. Did anything change in your qBitTorrent setup? A newer or older version? Anything config related?
@Flaminel commented on GitHub:
Did you set anything for qBit's user and password for cleanuperr? Or are you using the bypass?
@Flaminel commented on GitHub:
I've just tested with
lscr.io/linuxserver/qbittorrent:latestand it works just fine, so it might be something from your setup.@Flaminel commented on GitHub:
No problem! It's great that you fixed it!
@jgeorge1983 commented on GitHub:
I have a user and password set in qbt.
I just removed my password on cleanupper docker, restarted, added it again and restarted and its back again.
maybe i knocked it and left a whitespace? thanks for your help!!