Maintainerr findet Medien, löscht aber nicht

Warum Maintainerr Medien findet, aber nicht löscht

Wenn Maintainerr Medien findet, aber nicht löscht, ist die Regel fast nie das Problem. Eine Regel sortiert Filme und Serien nur in eine Sammlung ein. Gelöscht wird später, in einem eigenen Durchlauf. Das passiert erst, wenn eine Wartezeit abgelaufen ist und die gewählte Aktion überhaupt Dateien entfernt.

Diese Anleitung geht die Kette in der Reihenfolge durch, in der Maintainerr sie abarbeitet. Danach prüfst du sieben Ursachen, jede mit einem Test, den du selbst ausführen kannst. Alles hier bezieht sich auf Maintainerr 3.30.2 vom 18. Oktober 2026. Die Doku unter docs.maintainerr.info ist versioniert, und 3.30.2 ist dort die aktuelle Version.

Die Ausgangslage ist typisch für einen Heimserver oder einen VPS (virtueller privater Server): Plex, Jellyfin oder Emby als Medienserver, dazu Radarr und Sonarr in Docker. Die Maintainerr-Doku fasst Radarr und Sonarr als *arr zusammen. Hier heißen sie Arr-Dienste. Wenn du den Stack noch aufbaust, findest du die Grundlage in einem kompletten Arr-Stack mit Docker Compose.

Die Pipeline: Regel, Sammlung, Wartezeit, Aktion

Maintainerr arbeitet in vier Schritten. Jeder Schritt ist ein eigener Job mit eigenem Zeitplan.

1. Regel. Die Regelverarbeitung läuft als Batch alle 8 Stunden. Das Intervall ist in den Settings änderbar. Mit dem Knopf Run Rules auf der Seite Rules startest du sie sofort.
2. Sammlung. Jeder Treffer landet in der Sammlung (Collection) der Regelgruppe. Maintainerr speichert, wann der Eintrag hinzugekommen ist.
3. Wartezeit. Das Feld Media deleted after days legt fest, wie viele Tage ein Eintrag in der Sammlung bleibt, bevor etwas passiert. Erlaubt sind ganze Zahlen von 0 bis 36500. In Logs und älteren Issues heißt dasselbe Feld take action after days.
4. Aktion. Der Collection-Handler ist ein zweiter Batch und läuft alle 12 Stunden. Mit Handle Collections auf der Seite Collections startest du ihn von Hand. Er führt die Aktion der Regelgruppe für alle Einträge aus, deren Wartezeit abgelaufen ist.

Daraus folgt eine Rechnung, die viele unterschätzen. Nimm Media deleted after days = 30 und die Standard-Intervalle. Ein Film wartet bis zu 8 Stunden auf den nächsten Regellauf. Dann liegt er 30 Tage in der Sammlung. Dann wartet er bis zu 12 Stunden auf den nächsten Handler-Lauf. Ein Film, der heute zum ersten Mal auf die Regel passt, verschwindet also frühestens in einem Monat.

Ein Sonderfall verzögert zusätzlich: Wird ein fälliger Titel gerade gestreamt, schiebt Maintainerr ihn auf den nächsten Handler-Lauf.

Welche Aktionen es gibt

Für Radarr bietet eine Regelgruppe vier Aktionen: Delete, Unmonitor and delete files, Unmonitor and keep files und Change quality profile and search. Sonarr hat eigene Varianten für Serie, Staffel und Episode, zum Beispiel Delete entire show, Unmonitor and delete season oder Unmonitor and keep file.

Dazu kommen zwei Sonderfälle. Media server action löscht direkt über den Medienserver und gilt nur, wenn an der Regelgruppe kein Arr-Server ausgewählt ist. Do nothing tut genau das, was der Name sagt.

Seerr (der Anfrage-Manager für Wünsche deiner Nutzer) ist keine eigene Löschaktion. Die Option Force reset Seerr record löscht die Anfragen, statt auf den Abgleich von Seerr zu warten. Ist Seerr eingerichtet und hat ein Lauf Medien verändert, stößt Maintainerr danach den availability-sync von Seerr an.

Maintainerr 3.30.2 festnageln

Damit du dieselben Logzeilen und Menüs siehst wie hier beschrieben, pinne die Version. Das Image-Tag hat kein v davor. Auf GitHub heißt das Release v3.30.2. Das Image in der GitHub Container Registry heißt ghcr.io/maintainerr/maintainerr:3.30.2. Neben 3.30.2 gibt es dort auch 3.30, 3, latest und development.

Releases kommen oft, manchmal mehrere in einer Woche, manchmal mit gut zwei Wochen Abstand. Einen festen Rhythmus nennt das Projekt nicht. Lies vor jedem Update die Release Notes auf der GitHub-Seite des Projekts.

Lege zuerst das Datenverzeichnis an. Maintainerr läuft im Container als der Benutzer, den du unter user einträgst. Ohne Angabe ist das 1000:1000. Der Ordner muss für genau diese UID:GID lesbar und beschreibbar sein. Mit user: 1000:1000 wie in der Compose-Datei unten reicht dafür:

mkdir -p ~/maintainerr/data
sudo chown 1000:1000 ~/maintainerr/data
cd ~/maintainerr

Warum die Benutzer-ID zählt, erklärt PUID und PGID in Docker. Dann folgt die compose.yaml:

services:
  maintainerr:
    image: ghcr.io/maintainerr/maintainerr:3.30.2
    container_name: maintainerr
    user: 1000:1000
    volumes:
      - type: bind
        source: ./data
        target: /opt/data
    environment:
      - TZ=Europe/Berlin
      - LOG_LEVEL=debug
    ports:
      - 127.0.0.1:6246:6246
    restart: unless-stopped

/opt/data ist der Ort, an dem Maintainerr seine Konfiguration speichert. Ohne diesen Mount ist die Konfiguration weg, sobald der Container neu erstellt wird. Der Port ist an 127.0.0.1 gebunden, weil Docker eigene Firewall-Regeln setzt. Ein offener Port 6246 auf einem VPS wäre sonst aus dem Internet erreichbar. Setze TZ ausdrücklich. Die Zeitzone steuert die Zeitstempel im Log.

docker compose up -d
docker compose images maintainerr

In der Spalte für das Tag muss 3.30.2 stehen. Steht dort latest, läuft eine andere Compose-Datei. Die Oberfläche erreichst du dann über einen SSH-Tunnel von deinem Rechner aus:

ssh -L 6246:127.0.0.1:6246 user@dein-server

Danach öffnest du http://localhost:6246 im Browser.

Wo du die Maintainerr-Logs liest

Die Logs findest du in der Oberfläche unter Settings. Dort gibt es die Reiter General, Logs, Jobs und About. Im Reiter Logs stellst du auch ein, wie groß die Logdateien werden und wie viele Dateien Maintainerr behält.

LOG_LEVEL überschreibt die gespeicherte Log-Stufe für den laufenden Container. Erlaubt sind debug, verbose, info, warn, error und fatal. Für die Fehlersuche brauchst du debug. Die wichtigste Zeile, nämlich warum eine einzelne Sammlung übersprungen wird, erscheint nur auf dieser Stufe. Nach der Fehlersuche nimmst du die Zeile wieder aus der Compose-Datei.

Klicke jetzt auf Handle Collections und lies den Logs-Reiter. Der Handler schreibt eine Zusammenfassung. In 3.30.2 ist sie so aufgebaut, N steht jeweils für eine Zahl:

Collection handler summary: N total (isActive), N skipped (Do Nothing), N skipped (no window set), N skipped (no due media), N queued for handling

Diese eine Zeile sagt dir, in welchem Abschnitt unten du weiterlesen musst. skipped (Do Nothing) führt zu Ursache 2. skipped (no window set) bedeutet, dass das Feld für die Wartezeit leer ist, auch das steht bei Ursache 2. skipped (no due media) führt zu Ursache 1 oder 4. Steht bei total (isActive) eine kleinere Zahl als erwartet, lies Ursache 5. Ist queued for handling größer als null und der Speicher bleibt trotzdem voll, sind Ursache 3, 6 oder 7 dran.

Zwei weitere Zeilen beenden einen Lauf ohne Wirkung. Media server unreachable. Skipping collection handling. heißt, dass Maintainerr Plex, Jellyfin oder Emby nicht erreicht hat. All collections handled. No data was altered heißt, dass der Lauf fertig ist und nichts verändert hat.

Ursache 1: Die Wartezeit läuft noch

Das ist der häufigste Fall. Media deleted after days ist kein Zeitplan. Es ist eine Haltezeit pro Eintrag. Ein Eintrag ist erst fällig, wenn sein Hinzufügedatum mindestens so viele Tage zurückliegt. So steht es im Quellcode von 3.30.2: Fällig ist, was vor dem Zeitpunkt "jetzt minus Tage" in die Sammlung kam. Ein Film, der gestern in eine 30-Tage-Sammlung kam, bleibt also 29 weitere Tage liegen. Daran ändert auch häufiges Klicken auf Handle Collections nichts.

Im Debug-Log siehst du für jede solche Sammlung:

Skipping collection '<Titel>' because no media is due for handling

Prüfe in der Sammlung, wann die Einträge hinzugefügt wurden, und rechne die Tage dazu. Willst du die ganze Kette einmal schnell testen, setze eine Testsammlung mit einem einzigen unwichtigen Film auf 0 Tage. Bei 0 ist jeder Eintrag bei jedem Handler-Lauf fällig. Ein Maintainer schrieb 2024 dazu, dass 0 nicht getestet und nicht empfohlen sei. Nutze 0 also nur zum Testen und nie an einer Regel, die viele Titel trifft.

Was mit schon gesammelten Einträgen passiert, wenn du die Tageszahl später änderst, beschreibt die Doku nicht. Prüfe es an deiner Instanz: Wert ändern, speichern, Handle Collections klicken, die Zusammenfassung lesen.

Ein Sonderfall läuft andersherum. Change quality profile and search nutzt die Wartezeit nicht und ändert das Qualitätsprofil sofort.

Ursache 2: Die Aktion entfernt gar keine Dateien

Mehrere Aktionen lassen die Dateien absichtlich auf der Platte. Sie funktionieren dann korrekt, nur nicht so, wie du es erwartest.

• Do nothing tut nichts. Der Handler überspringt solche Sammlungen ganz und schreibt Skipping collection '<Titel>' as its action is 'Do Nothing'.
• Unmonitor and keep files ändert in Radarr nur das Monitored-Flag. Laut Doku werden keine Dateien und keine Ordner angefasst.
• Die Sonarr-Varianten mit keep files oder keep file im Namen verhalten sich genauso, ebenso Unmonitor season + unmonitor show if empty.
• Change quality profile and search tauscht das Profil und startet eine neue Suche. Es löscht nichts.

Öffne die Regelgruppe und lies die gewählte Aktion. Wenn du Platz gewinnen willst, brauchst du bei Radarr Delete oder Unmonitor and delete files. Bei Sonarr brauchst du eine Variante mit delete im Namen.

Die Option Keep in Maintainerr only ist dagegen keine Ursache. Sie legt die Sammlung nur nicht auf dem Medienserver an. Regeln, Aktionen und Arr-Tags arbeiten laut Doku weiter.

Steht im Log Skipping collection '<Titel>' as it has no 'take action after days' set, ist das Feld für die Wartezeit leer. Ältere Versionen ließen das Feld leer, wenn man von Do nothing auf eine andere Aktion wechselte. Das wurde in v2.21.0 behoben. Prüfe trotzdem, dass dort eine Zahl steht, und speichere.

Ursache 3: Kein Radarr- oder Sonarr-Server an der Regelgruppe

Jede Regelgruppe hat ein Feld Radarr server beziehungsweise Sonarr server. Die Doku sagt dazu: Die Radarr-Konfiguration ist nötig, um ihre Parameter in Regeln zu nutzen und um Filme zu entfernen oder nicht mehr zu überwachen. Was ohne diesen Eintrag passiert, hängt von der Aktion ab.

• Eine Aktion, die nur das Monitoring ändert, braucht den Arr-Dienst. Ein Profilwechsel auch. Ohne ihn schreibt der Handler eine Zeile, die mit *arr action isn't possible without *arr configured beginnt, und erledigt nichts.
• Eine löschende Aktion weicht auf den Medienserver aus. Die Logzeile beginnt mit Couldn't utilize *arr to find and remove the media with id. Dann löscht Maintainerr über die API (die Programmierschnittstelle) von Plex, Jellyfin oder Emby. Bei Erfolg steht im Log Successfully deleted Jellyfin item <id> from disk, bei Plex dieselbe Zeile mit Plex. Bei einem Fehler steht dort Failed to delete item <id> from disk.

Ob Plex dafür die Einstellung zum Löschen von Medien braucht, oder Jellyfin eine Löschberechtigung für den Benutzer, haben wir für 3.30.2 nicht bestätigt. Prüfe das in der Doku deines Medienservers, wenn du diesen Weg nutzt. Sauberer ist ohnehin, den Arr-Dienst einzutragen. Dann weiß Radarr, dass der Film weg ist. Löscht nur der Medienserver, bleibt der Film in Radarr überwacht und gilt dort als fehlend.

Auch mit eingetragenem Server gibt es zwei Ausweichwege. Findet Radarr den Film nicht, versucht Maintainerr bei löschenden Aktionen, die Datei über den Medienserver zu entfernen. Ist Radarr gar nicht erreichbar, schreibt der Handler No action was taken; will retry next run. und löscht nichts. Sonarr verhält sich genauso.

Ob Radarr antwortet und dein API-Schlüssel stimmt, prüfst du vom Server aus. Das setzt voraus, dass der Radarr-Port auf dem Host veröffentlicht ist:

curl -s -H "X-Api-Key: DEIN_RADARR_KEY" http://127.0.0.1:7878/api/v3/system/status

Eine Antwort mit "appName": "Radarr" und einer Versionsnummer ist gesund. Für Sonarr nimmst du Port 8989 und den Sonarr-Schlüssel. Bedenke: In Maintainerr trägst du die Adresse ein, unter der der Arr-Dienst aus dem Maintainerr-Container heraus erreichbar ist. Ein Dienstname wie http://radarr:7878 funktioniert nur, wenn beide Container im selben Docker-Netz hängen. Wie du Adressen und Schlüssel zwischen den Diensten sauber verdrahtest, zeigt Prowlarr, Sonarr, Radarr und den Download-Client verbinden.

Ursache 4: Radarr oder Sonarr antworten nicht, also hält Maintainerr zurück

Diese Ursache sieht aus wie Ursache 1, hat aber einen anderen Grund. In Issue 3761 (geschlossen am 21. September 2026) meldete ein Nutzer, dass Unmonitor and delete files nichts tat. Die Zusammenfassung zeigte 8 skipped (no due media), 0 queued for handling. Weiter oben im Log standen beim Regellauf Fehler wie Error retrieving movie by TMDb ID und Error retrieving show by tvdb ID.

Ein Maintainer erklärte, dass Einträge absichtlich zurückgehalten werden, wenn Radarr oder Sonarr nicht antworten. Das ist eine Schutzfunktion: Maintainerr löscht nichts, dessen Zustand es im Arr-Dienst nicht prüfen konnte. Bei diesem Nutzer funktionierte das Löschen wieder, nachdem er die Radarr- und Sonarr-Einstellungen in Maintainerr neu gespeichert hatte. Die eigentliche Ursache blieb offen.

Daraus folgt eine Reihenfolge, die nichts kostet:

1. Settings öffnen, den Radarr- und den Sonarr-Eintrag öffnen und neu speichern.
2. Run Rules auf der Seite Rules klicken und warten, bis der Lauf fertig ist.
3. Das Log nach Error retrieving durchsuchen. Steht dort nichts mehr, geht es weiter.
4. Handle Collections klicken und die Zusammenfassung lesen.

Die Doku sagt nicht, dass nach einer Änderung an einer Regelgruppe ein neuer Regellauf nötig ist. Ein manueller Lauf schließt die Frage aber aus. Ein älterer Fall zeigt, warum das hilft. In Issue 949 änderte ein Nutzer 2024 auf einem Entwicklungs-Build die Tage von 7 auf 0, drückte Run Rules und sah danach eine andere Zahl als 0. Das ist nicht das Verhalten von 3.30.2. Es zeigt aber: Lies nach jeder Änderung nach, welcher Wert wirklich gespeichert ist.

Ursache 5: Ausnahmen, inaktive Gruppen und manuelle Einträge

Eine Ausnahme (Exclusion) nimmt einen Titel aus der Bearbeitung. Der Handler streicht ausgeschlossene Einträge aus der Liste der fälligen Titel. Eine Ausnahme, die an eine bestimmte Sammlung gebunden ist, gilt nur dort. Eine globale Ausnahme gilt überall und entfernt die sammlungsbezogenen Ausnahmen dieses Titels. Wenn also genau ein Film nie verschwindet, suche ihn zuerst in den Ausnahmen.

Steht Active an der Regelgruppe auf aus, läuft die Regel nicht. Der Handler lädt außerdem nur aktive Sammlungen. Wichtig: Eine deaktivierte Gruppe leert ihre Sammlung nicht. Die Einträge bleiben sichtbar, und trotzdem passiert nichts. Willst du eine Sammlung leeren, lass die Regel nichts mehr treffen, führe sie einmal aus und deaktiviere sie erst dann.

Manuell hinzugefügte Einträge ignoriert der Regelprozessor. Eine Regel wirft einen manuellen Eintrag also nie wieder hinaus. Die Doku warnt aber ausdrücklich: MANUAL does not mean protected. Ein manueller Eintrag schützt nicht vor dem Löschen. Wer einen Titel behalten will, setzt eine Ausnahme.

Ursache 6: Gelöscht, aber Plex oder Jellyfin zeigen den Titel noch

Hier hat Maintainerr seine Arbeit getan. Radarr hat die Datei gelöscht, aber der Medienserver kennt sie noch, weil er die Bibliothek nicht neu eingelesen hat. Der Titel steht weiter in der Übersicht, und es wirkt, als sei nichts passiert.

Seit v3.29.0 (16. September 2026) stößt Maintainerr direkt nach einem Löschen über Radarr oder Sonarr einen gezielten Rescan des betroffenen Ordners im Medienserver an. Der Titel verschwindet dann, ohne dass du auf den nächsten vollen Bibliotheks-Scan wartest. Läuft bei dir eine ältere Version, aktualisiere auf 3.30.2 oder starte den Scan der Bibliothek im Medienserver von Hand.

Prüfe zuerst, ob die Datei wirklich weg ist. Bei Radarr steht im Maintainerr-Log Removed movie with <provider> ID <id> from filesystem & Radarr. Auf dem Server prüfst du mit ls im Filmordner. Ist der Ordner leer oder fehlt er, liegt das Problem beim Medienserver und nicht bei Maintainerr. Wie Jellyfin seine Bibliotheken im Stack einliest, beschreibt Jellyfin zum Arr-Stack hinzufügen.

Ursache 7: Datei gelöscht, Speicher bleibt voll (Hardlinks)

Das ist die verwirrendste Ursache, weil alles richtig aussieht. Radarr meldet den Film als gelöscht, der Medienserver zeigt ihn nicht mehr, und df -h zeigt denselben freien Platz wie vorher.

Der Grund sind Hardlinks. In einem gut eingerichteten Stack legt Radarr den fertigen Download nicht als Kopie in die Bibliothek, sondern als Hardlink. Ein Hardlink ist ein zweiter Dateiname für dieselben Daten auf der Platte. Der Speicher wird erst frei, wenn der letzte Name gelöscht ist. Radarr löscht den Namen in der Bibliothek. Der Name im Download-Ordner, aus dem dein Torrent-Client noch seedet, bleibt bestehen.

Prüfe die Anzahl der Namen, bevor Maintainerr löscht:

stat -c '%h %n' /data/media/movies/Beispielfilm/Beispielfilm.mkv

Die erste Zahl ist die Linkanzahl. Eine 2 heißt: Es gibt noch einen zweiten Namen. Den findest du so:

find /data -samefile /data/media/movies/Beispielfilm/Beispielfilm.mkv

Nach dem Löschen suchst du Kandidaten im Download-Ordner, die nur noch einen einzigen Namen haben. Das sind Dateien, die nicht mehr in der Bibliothek liegen:

find /data/torrents -type f -links 1 -size +500M

Die Pfade /data/media und /data/torrents sind Beispiele für die übliche Ordnerstruktur. Warum Download- und Bibliotheksordner auf demselben Dateisystem liegen müssen, damit Hardlinks überhaupt entstehen, erklärt die Ordnerstruktur für den Arr-Stack und Hardlinks.

Der Download-Client in Maintainerr

Maintainerr kann den Torrent samt Daten mit entfernen. Die Release Notes nennen das Job-Cleanup, in der Doku heißt der Bereich Download Client. Er erscheint unter Services erst, wenn Radarr oder Sonarr eingerichtet sind. Die Grenzen in 3.30.2:

• Unterstützt werden nur qBittorrent und Transmission. Transmission kam mit v3.28.0 am 11. September 2026 dazu.
• Was über einen anderen Client geladen wurde, zum Beispiel per Usenet, findet Maintainerr nicht und lässt es unangetastet.
• Die Bereinigung läuft nur, wenn Radarr oder Sonarr löschen, und nur bei Delete und Unmonitor and delete files. Bei Unmonitor and keep files und beim Profilwechsel läuft sie nie.
• Bei Sonarr läuft sie laut Doku nur, wenn die ganze Serie gelöscht wird. Rechne bei Staffel- oder Episodenaktionen nicht damit, dass Staffelpakete mit verschwinden.
• Der Eintrag muss auf dieselbe qBittorrent- oder Transmission-Instanz zeigen, die auch Radarr und Sonarr nutzen.
• Teilt sich ein anderer Torrent dieselben Dateien, entfernt Maintainerr nur den Torrent-Eintrag und behält die Daten.

Die Bereinigung arbeitet nach bestem Bemühen. Erreicht Maintainerr den Client nicht, löscht der Arr-Dienst trotzdem, und der Hardlink im Download-Ordner bleibt. Ein 403 Forbidden nach dem Login bedeutet laut Doku meist, dass die Sicherheitseinstellungen der qBittorrent-Weboberfläche die Anfrage blockiert haben.

Muss Maintainerr den Medienordner mounten?

Für Löschen, Unmonitor und Profilwechsel: nein. Die Aktions-Handler in 3.30.2 rufen die API von Radarr, Sonarr oder dem Medienserver auf. Die Datei löscht der Arr-Dienst oder der Medienserver, nicht Maintainerr selbst. Deshalb hat die Compose-Datei oben keinen Medien-Mount.

Die einzige Ausnahme ist die Option Clean up leftover folders (BETA). Sie ist standardmäßig aus und räumt Ordner auf, die nach dem Löschen übrig bleiben. Dafür muss die Bibliothek im Maintainerr-Container unter genau demselben Pfad liegen, den der Arr-Dienst meldet, und sie muss beschreibbar sein. Die Doku sagt klar: Dieselben Daten unter einem anderen Containerpfad funktionieren nicht. Mountet Radarr /data/media, ergänzt du bei Maintainerr unter volumes:

      - type: bind
        source: /data/media
        target: /data/media

Hänge kein :ro an. Stimmt der Pfad nicht, schreibt Maintainerr eine Zeile, die mit mount the library at the same path the *arr uses. Skipping. endet, und lässt den Ordner stehen. Liegt deine Bibliothek auf einem großen Speicher-VPS oder einem eigenen Volume, hilft ein Medienserver auf einem Storage-VPS beim Planen der Pfade.

Die Prüfung in der richtigen Reihenfolge

1. LOG_LEVEL=debug setzen, docker compose up -d ausführen und mit docker compose images maintainerr prüfen, dass 3.30.2 läuft.
2. In der Regelgruppe die Aktion lesen. Sie muss Dateien löschen.
3. Prüfen, dass ein Radarr- oder Sonarr-Server ausgewählt ist und Active eingeschaltet ist.
4. Radarr- und Sonarr-Einstellungen neu speichern, dann Run Rules klicken.
5. Handle Collections klicken und die Zusammenfassung im Logs-Reiter lesen.
6. Hinzufügedatum plus Media deleted after days ausrechnen.
7. Nach dem Löschen mit stat und find -samefile prüfen, ob ein Hardlink den Speicher festhält.

FAQ

Warum zeigt Maintainerr Treffer an, löscht aber nichts?

Eine Regel füllt nur die Sammlung. Gelöscht wird erst, wenn die Wartezeit Media deleted after days für den Eintrag abgelaufen ist und der Collection-Handler läuft. Der läuft alle 12 Stunden oder per Klick auf Handle Collections. Prüfe außerdem, dass die Aktion Dateien löscht. Do nothing, Unmonitor and keep files und Change quality profile and search lassen die Dateien auf der Platte.

Was bedeutet skipped (no due media) im Maintainerr-Log?

Kein Eintrag dieser Sammlung ist fällig. Meist läuft die Wartezeit noch. Es kann aber auch sein, dass Radarr oder Sonarr beim Regellauf nicht geantwortet haben. Dann stehen weiter oben Fehler wie Error retrieving movie by TMDb ID, und Maintainerr hält die Einträge absichtlich zurück. Speichere die Radarr- und Sonarr-Einstellungen neu und führe Run Rules aus.

Warum wird nach dem Löschen kein Speicherplatz frei?

Meist hält ein Hardlink im Download-Ordner die Daten fest, weil dein Torrent-Client die Datei noch seedet. stat -c '%h %n' <datei> zeigt dann eine Linkanzahl größer als 1. Maintainerr 3.30.2 kann den Torrent mit entfernen, aber nur bei qBittorrent und Transmission und nur bei den Aktionen Delete und Unmonitor and delete files.

Braucht der Maintainerr-Container Zugriff auf meine Mediendateien?

Für die normalen Aktionen nicht. Maintainerr löscht über die API von Radarr, Sonarr oder dem Medienserver. Nur die Beta-Option Clean up leftover folders braucht die Bibliothek im Container, unter genau demselben Pfad wie bei Radarr oder Sonarr und beschreibbar.

Welches Image-Tag nutze ich für Maintainerr 3.30.2?

Das Tag ist ghcr.io/maintainerr/maintainerr:3.30.2, ohne v vor der Versionsnummer. Das v gehört nur zum Release-Namen auf GitHub. Mit docker compose images maintainerr siehst du, welches Tag wirklich läuft.