Sonarr: TV-Automatisierung, mit der Usenet erst richtig glänzt

Ein Season-Pack von Hand zu ziehen ist einmal okay. Ein Dutzend laufende Serien aktuell zu halten — neue Episoden, Proper-Releases statt Pre-Airs, Quality-Upgrades, sobald ein besserer Encode auftaucht — ist kein Job für Handarbeit. Genau diese Kategorie Arbeit lässt Sonarr verschwinden: Serie einmal hinzufügen, und ab dann kommen Episoden an, werden umbenannt und landen in der Bibliothek, ohne dass man irgendetwas anfasst.

Was Sonarr tatsächlich automatisiert

Sonarr ist ein Open-Source-PVR für Usenet (und BitTorrent). Man fügt eine Serie hinzu, wählt ein Qualitätsprofil, und Sonarr übernimmt den kompletten Lebenszyklus:

• Monitoring — Ausstrahlungstermine werden über Metadaten-Provider verfolgt; die Suche startet, sobald eine Episode verfügbar ist, inklusive Backfill ganzer Back-Kataloge bei neu hinzugefügten Serien
• Suche — Anfragen gehen an die konfigurierten newznab-Indexer; Releases werden gegen Qualitäts- und Spracheinstellungen gescort, bevor irgendetwas gegriffen wird
• Download-Übergabe — das gewählte NZB geht direkt an SABnzbd oder NZBGet
• Import und Umbenennung — fertige Downloads wandern mit konsistentem, konfigurierbarem Naming in die Bibliothek, das Plex, Jellyfin und Emby sauber parsen
• Upgrades — taucht ein WEB-DL für eine Episode auf, die nur in HDTV-Qualität vorliegt, ersetzt Sonarr sie automatisch, bis zum definierten Cutoff

Seit v4 laufen Qualitätsentscheidungen über Custom Formats — gescorte Regeln, mit denen sich bestimmte Release-Gruppen, Codecs oder HDR-Varianten bevorzugen und andere verbannen lassen. Kombiniert mit den geteilten Scoring-Profilen der TRaSH-Guides ist das deutlich präziser, als es das alte Preferred-Words-System je war.

Warum die Usenet-Kombination so stark ist

Sonarr funktioniert auch mit Torrents, aber wirklich wartungsfrei wird es erst im Usenet-Gespann — aus einem Hauptgrund: Failed Download Handling. Kommt ein Download unvollständig an — fehlende Artikel, gescheiterter Repair — meldet SABnzbd den Fehlschlag zurück, und Sonarr greift sofort und automatisch das nächstbeste Release von einem anderen Indexer. Mit zwei, drei soliden Indexern dahinter kostet ein kaputter Download nichts außer ein paar Minuten Verzögerung, die niemand bemerkt.

Auch der Rest des Usenet-Profils passt zur Automatisierung: Downloads füllen die Leitung aus, statt von Seedern abzuhängen, es gibt keine Ratio-Verpflichtungen für Inhalte, die man nur einmal brauchte, und eine über Nacht gepostete Episode liegt morgens in der Bibliothek. Retention, die tief genug reicht, um eine zehn Jahre alte Serie komplett nachzuziehen, schadet ebenfalls nicht.

Auf dem NAS oder Selfhost-Server mit Docker

Sonarrs Job ist es, auf Dinge zu reagieren, die passieren, während man nicht am Rechner sitzt. Das natürliche Zuhause ist deshalb eine Maschine, die immer läuft — ein NAS, ein Homeserver, eine kleine Kiste im Schrank. Docker ist der Weg des geringsten Widerstands: Das linuxserver.io-Image wird gut gepflegt, Updates sind ein docker compose pull entfernt, und die gesamte Konfiguration liegt in einem einzigen gemounteten Ordner.

services:
  sonarr:
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
    volumes:
      - ./config:/config
      - /srv/media:/data
    ports:
      - "8989:8989"
    restart: unless-stopped

Ein Detail, das man von Anfang an richtig machen sollte: Downloads und Bibliothek unter einem einzigen Volume mounten (hier /data, mit z. B. /data/usenet und /data/tv). Dann sind Importe sofortige Hardlinks oder atomare Moves statt langsamer Kopien über Mount-Grenzen hinweg — die mit Abstand häufigste Stolperfalle in *arr-Docker-Setups.

Auf Synology und QNAP funktioniert dieselbe Compose-Datei über den Container Manager; SynoCommunity paketiert Sonarr auch nativ, falls man auf älteren Modellen Docker vermeiden will.

Lokale Installation geht genauso

Niemand ist auf einen Server festgelegt. Sonarr liefert native Installer für Windows (läuft als Tray-App oder Dienst), macOS und Linux. Seit v4 läuft es auf modernem .NET ohne Mono-Abhängigkeit — eine lokale Installation ist eine Sache von zwei Minuten. Das ist ein völlig legitimer Weg, um das Tool zu evaluieren oder ein kleines Setup auf einem Desktop zu fahren, der ohnehin den größten Teil des Tages an ist.

Die ehrliche Einschränkung: Sonarr automatisiert nur, solange es läuft. Ein PC, der nachts schläft, holt nach dem Aufwachen auf — Sonarr sucht alles Verpasste nach —, aber erst die Always-on-Kiste macht die Erfahrung wirklich Zero-Touch. Viele fangen lokal an und ziehen später aufs NAS um; der Umzug ist schmerzfrei, weil der gesamte Zustand in einem Config-Ordner liegt, den man einfach rüberkopiert.

Wo es im Stack sitzt

Sonarr ist der Entscheider — nicht der Downloader und nicht der Indexer. Es braucht newznab-Endpunkte auf der einen Seite — entweder direkt eingetragene Indexer oder aggregiert hinter NZBHydra2 oder Prowlarr, damit API-Keys an einer Stelle verwaltet werden — und SABnzbd oder NZBGet auf der anderen. Radarr (Filme) und Lidarr (Musik) folgen demselben Muster, weshalb die ganze Familie meist zusammen als ein Compose-Stack deployt wird.

Wenn TV der Grund ist, warum man seine Usenet-Abos behält, ist Sonarr das Tool, das sie rechtfertigt: Es macht aus Indexern, Provider und Downloader ein System, das die Bibliothek schlicht von allein aktuell hält.

Projekt-Website: sonarr.tv