SuggestArr: Empfehlungen aus der Sehhistorie automatisch an Seer übergeben

Welche Lücke SuggestArr zwischen Wiedergabe und Anfrage schließt

Ein Media-Server weiß, was jemand gesehen hat. Seer weiß, was jemand anfordern kann. Dazwischen liegt normalerweise ein Mensch, der sich selbst überlegt, was als Nächstes passt, den Titel bei Seer sucht und die Anfrage stellt. SuggestArr besetzt genau diesen Zwischenschritt: Es liest die zuletzt gesehenen Inhalte aus Jellyfin, Plex oder Emby, sucht über die TMDb-API nach ähnlichen Filmen und Serien und leitet daraus Download-Anfragen an Seer weiter.

Die Zielgruppe ist damit klar umrissen. Angesprochen sind Betreiber selbst gehosteter Setups, die bereits einen Seer-Dienst und mindestens einen der drei unterstützten Media-Server betreiben und die Bibliothek ohne manuelles Zutun aktuell halten wollen. Das Projekt ist kein Empfehlungsdienst für Endnutzer ohne eigene Infrastruktur, sondern ein Bindeglied zwischen zwei Systemen, die sonst getrennt bleiben.

Der README beschreibt daneben zwei optionale Erweiterungen, die über die reine Ähnlichkeitssuche hinausgehen: eine KI-gestützte Empfehlung auf Basis eines OpenAI-kompatiblen LLM, laut Dokumentation als Beta gekennzeichnet, sowie eine Trakt-Anbindung, bei der jeder Nutzer sein eigenes Trakt-Konto verknüpft und dessen zuletzt gesehene Titel als zusätzliche Grundlage dienen.

Der Ablauf: Sehhistorie, TMDb-Ähnlichkeit, Seer-Anfrage

Der Mechanismus ist eine Kette mit drei klar getrennten Stationen. Am Anfang steht die Abfrage der Wiedergabehistorie beim konfigurierten Media-Server. Daraus entsteht die Menge der Titel, die als Ausgangspunkt für Empfehlungen dienen. Im zweiten Schritt fragt SuggestArr die TMDb-API nach ähnlichen Inhalten ab. TMDb ist damit keine Nebenbedingung, sondern die eigentliche Empfehlungslogik: Was als ähnlich gilt, entscheidet der Dienst, nicht SuggestArr selbst. Im dritten Schritt werden die gefundenen Titel als Anfragen an Seer übergeben.

Dazwischen liegen Filter, die verhindern sollen, dass offensichtlich Unpassendes durchgereicht wird. Der README nennt eine Inhaltsfilterung, die Anfragen für Titel unterdrückt, die in der jeweiligen Region bereits bei Streaming-Anbietern verfügbar sind. Bei aktivierter Trakt-Anbindung kommen zwei weitere Regeln hinzu: zuletzt gesehene Trakt-Inhalte können als zusätzliche Ausgangspunkte dienen, und vollständig auf Trakt gesehene Titel wandern in eine Ausschlussmenge.

Bemerkenswert ist, was der Ablauf nicht enthält. Es gibt keine Gewichtung, keine Rückmeldung darüber, ob eine vorgeschlagene Anfrage später tatsächlich abgespielt wurde, und keine sichtbare Korrektur der Empfehlungslogik anhand dieses Ergebnisses. Die Kette bleibt eine Einbahnstraße von der Historie zur Anfrage.

Genehmigungen, Pausen und Aufräumen als eigentliche Steuerung

Interessanter als die Empfehlungskette ist der Kontrollapparat darüber. Neue Jobs folgen laut README der globalen Einstellung 'Approve requests before sending them to Seer', die standardmäßig deaktiviert ist und unter 'Advanced' liegt. Jeder Job kann diese Vorgabe erben oder sie überschreiben, um entweder immer freizugeben oder immer automatisch zu senden. Zurückgehaltene Ergebnisse erscheinen auf der Requests-Seite, wo der Job-Eigentümer oder ein Administrator sie an Seer senden, ablehnen oder global blockieren kann.

Dazu kommen zwei Pausenmechanismen. Der eine hält einen Job an, solange Seer noch offene Anfragen zur Genehmigung oder Ablehnung hat. Der andere pausiert geplante Empfehlungsjobs, wenn ein Nutzer eine von SuggestArr stammende Anfrage innerhalb einer konfigurierbaren Zahl von Tagen nicht gesehen hat. Manuelle Läufe bleiben in diesem Fall möglich, was sinnvoll ist: Wer bewusst einen Durchlauf startet, will nicht durch eine Automatik ausgebremst werden.

Schließlich gibt es eine Aufräumautomatik, die alte, von SuggestArr stammende Anfragen und Dateien entfernt, wenn Nutzer sie in Plex, Jellyfin oder Emby nie favorisiert haben. Das ist die aggressivste der Optionen, weil sie nicht nur Anfragen, sondern auch Dateien betrifft. Wer sie aktiviert, sollte vorher wissen, wie seine Nutzer mit Favoriten umgehen.

Installation über Docker Compose und der Weg durch die Weboberfläche

Der README liefert ein Docker-Compose-Beispiel. Der Dienst heißt darin suggestarr, das Image ist ciuse99/suggestarr:latest, alternativ steht ghcr.io/giuseppe99barchetta/suggestarr:latest bereit. Der Container läuft mit restart: always, ein Volume bindet ./config_files auf /app/config/config_files, und der Port wird über die Variable SUGGESTARR_PORT gesteuert, die auf 5000 zurückfällt. Gestartet wird mit docker-compose up.

Als Umgebungsvariablen nennt das Beispiel nur LOG_LEVEL, standardmäßig info, und SUGGESTARR_PORT. Die eigentliche Konfiguration läuft nicht über Umgebungsvariablen, sondern über die Weboberfläche unter http://localhost:5000 beziehungsweise dem gesetzten Port. Dort werden der Media-Server, die API-Schlüssel und der Cron-Zeitplan eingerichtet. Der README erwähnt eine Vorabprüfung, die API-Schlüssel und URLs bereits während der Einrichtung validiert.

Für Anfragen unter einem bestimmten Seer-Nutzer sind vier Schritte beschrieben: die Nutzerauswahl in der Oberfläche aktivieren, den gewünschten Nutzer aus der Auswahlliste nehmen, dessen Passwort eingeben, danach laufen die Anfragen über dieses Profil statt über den Administrator. Der README schränkt das ausdrücklich ein: Unterstützt werden derzeit nur lokale Seer-Nutzer.

Die Trakt-Anbindung folgt einem getrennten Muster. Ein Administrator legt bei Trakt eine OAuth-Anwendung an und trägt unter Services -> Trakt die Client ID und das Client Secret ein. Jeder Nutzer verknüpft anschließend selbst unter Profile -> Trakt Account sein Konto. Ein aufklappbares Panel 'Recent Trakt Preview' zeigt die zuletzt von Trakt geholten Einträge.

Wo SuggestArr an Grenzen stößt

Die erste Einschränkung steckt im Kern: Die Qualität der Vorschläge hängt vollständig an der Ähnlichkeitslogik von TMDb. Wer schon einmal gesehen hat, was TMDb als ähnlich ausgibt, weiß, dass Genre-Nähe und Stimmungsnähe zwei verschiedene Dinge sind. SuggestArr hat darauf keinen Einfluss und bietet laut README auch keine Möglichkeit, die Gewichtung nachzujustieren. Die KI-gestützte Empfehlung ist als Beta gekennzeichnet und damit kein Ersatz für eine belastbare Kuratierung.

Zweitens ist die Standardeinstellung für Genehmigungen deaktiviert. Wer den Container startet und die Oberfläche nur oberflächlich einrichtet, betreibt eine Anlage, die ohne Zwischenprüfung Anfragen an Seer stellt. Das ist kein Fehler des Projekts, aber eine Voreinstellung, die man bewusst zur Kenntnis nehmen sollte.

Drittens die Aufräumautomatik: Sie löscht Dateien, wenn Nutzer sie nie favorisiert haben. In Haushalten, in denen Favoriten selten gesetzt werden, kann das mehr entfernen als beabsichtigt.

Viertens die Datenhaltung. Standardmäßig kommt SQLite zum Einsatz. PostgreSQL und MySQL werden unterstützt, der README nennt sie als Option für bessere Skalierbarkeit. Bei mehreren Nutzern und parallelen Jobs ist die Standarddatenbank eine Frage, die man vor dem Wachstum klären sollte, nicht danach.

Schließlich die Trakt-Anbindung: Sie erfordert eine eigene OAuth-Anwendung, Administrator-Zugang für die gemeinsamen Zugangsdaten und einen manuellen Verknüpfungsschritt pro Nutzer. In Installationen, in denen Nutzer ihre Konten nicht selbst pflegen, bleibt dieses Feature ungenutzt.

Was SuggestArr von Ombi und Overseerr unterscheidet

Die naheliegende Alternative ist der direkte Weg: Nutzer stellen ihre Anfragen selbst über die Oberfläche von Seer, Overseerr oder Ombi. Diese Werkzeuge sind auf genau das ausgelegt, auf Suche, Anfrage, Genehmigung, und sie sind ausgereift. Der Unterschied liegt nicht in der Funktion, sondern in der Richtung. Dort geht der Impuls vom Nutzer aus, hier von der Wiedergabehistorie. SuggestArr automatisiert einen Vorgang, den ein Mensch sonst bewusst auslöst.

Das ist ein anderes Versprechen und bringt ein anderes Risiko mit sich. Eine Anfrage, die jemand selbst stellt, ist bereits gefiltert. Eine Anfrage, die aus einem Ähnlichkeitsalgorithmus entsteht, nicht. Deshalb ist der Genehmigungsworkflow in SuggestArr nicht Beiwerk, sondern die Bedingung dafür, dass das Modell funktioniert. Wer ihn abschaltet, betreibt faktisch einen ungeprüften Zulieferer für Seer.

Gegenüber einer reinen TMDb-Empfehlungsliste, die manuell abgearbeitet wird, gewinnt SuggestArr durch die direkte Anbindung an Seer und die Pausenlogik, die auf offene Anfragen und ausbleibende Wiedergaben reagiert. Gegenüber einem Skript, das dieselbe Kette selbst zusammenbaut, gewinnt es durch die Weboberfläche, die Cron-Verwaltung und die Nutzerzuordnung. Diese Punkte sind der eigentliche Aufwand, den das Projekt abnimmt.

Betrieb, Lizenz und der Aufwand für Aktualisierungen

SuggestArr steht unter der MIT-Lizenz. Das ist eine der permissivsten Lizenzen: Nutzung, Veränderung und Weitergabe sind erlaubt, sofern der Lizenztext und der Urheberrechtsvermerk erhalten bleiben. Für den Selbstbetrieb ändert das praktisch nichts. Wer den Code jedoch in ein eigenes Produkt einbettet, sollte die Bedingungen der MIT-Lizenz im Detail prüfen und sich dazu gegebenenfalls beraten lassen; eine rechtliche Einschätzung kann dieser Text nicht liefern.

Der Release-Verlauf deutet auf einen aktiven Rhythmus hin: v2.12.0, v2.13.0 und v2.14.0 liegen laut Repository in Abständen von wenigen Wochen. Wer den Container mit dem Tag latest betreibt, bekommt diese Änderungen ungefragt mit. Das ist bei einem Dienst, der Dateien löschen und Anfragen an ein anderes System stellen kann, ein relevantes Risiko. Ein festes Tag statt latest ist hier die naheliegende Absicherung. Der README nennt keine Upgrade-Prozedur und keine Angaben dazu, ob Datenbankschemata zwischen Versionen migriert werden. Wer ein externes PostgreSQL oder MySQL einsetzt, sollte das vor einem Versionssprung selbst prüfen, weil dazu im vorliegenden Material nichts steht.

Ein Punkt, der sich aus dem Repository-Layout ableiten lässt, aber nicht bestätigt ist: Der Build-Workflow trägt den Namen docker_hub_build.yml, die Images werden also offenbar automatisiert veröffentlicht. Angaben zu Testabdeckung oder unterstützten Versionen der Media-Server macht der README nicht.

Redaktionelles Fazit

SuggestArr passt zu Betreibern, die bereits Seer und einen der drei Media-Server laufen haben und die Lücke zwischen Sehhistorie und Anfrage-Warteschlange schließen wollen. Wer keine Kontrolle über TMDb-Ergebnisse braucht oder wem ein einzelner Nutzer als Anfragequelle genügt, gewinnt wenig. Vor dem Produktivbetrieb würde ich die globale Einstellung 'Approve requests before sending them to Seer' aktivieren, einen einzelnen Job mit kurzem Cron-Intervall anlegen und die Einträge auf der Requests-Seite prüfen, bevor irgendetwas automatisch an Seer geht.

Offizielle Quellen

1. giuseppe99barchetta/SuggestArr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases