ScarriffleandClaude Opus 5
632d3efa35
Je Mediathek einstellbar, Vorgabe aus: wer eine Mediathek anlegt, will sie sehen. Angeschaltet warten neue Funde unter "Zu prüfen", bis jemand sie freigibt — oder ihnen einen Termin gibt. Ein Zeitpunkt, kein Zustandsfeld. PublishAt null heisst wartet, in der Vergangenheit heisst veröffentlicht, in der Zukunft heisst geplant. Die Sichtbarkeit wird bei der Abfrage gerechnet statt von einem Dienst umgeschaltet; damit stimmt sie nach einem Neustart, nach einer Zeitumstellung und auch dann, wenn der Server zum geplanten Zeitpunkt gar nicht lief. Ein Ticker hätte in jedem dieser Fälle das Falsche getan. Das eigentliche Risiko waren die zwanzig Abfragestellen in vier Dateien. Schriebe jede ihren eigenen Filter, reichte eine vergessene — und auffallen würde es nicht beim Programmieren, sondern wenn jemand im Haushalt einen Titel sieht, den er nicht sehen sollte. Deshalb ein globaler Abfragefilter in FlaroContext, der sich nicht vergessen lässt, und eine Middleware, die je Anfrage setzt, wer Unveröffentlichtes sehen darf. Vorgabe am Kontext ist "alles sehen", damit Scanner und Metadaten ohne Benutzer arbeiten können; für jede HTTP-Anfrage entscheidet die Middleware. Der Test zählt die Inhaltsrouten auf und prüft jede einzeln auf die Abwesenheit eines wartenden Titels. Eine neue Route, die den Filter umgeht, fällt dort durch. Die Migration trägt für alle vorhandenen Titel das Hinzufügedatum als Veröffentlichung nach. Ohne diese zwei Zeilen stünde jeder auf null — und der gesamte Bestand wäre für alle ausser Administratoren verschwunden, sofort beim Start im Container und ohne Meldung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Flaro Web
Die Weboberfläche für Rechner, auf denen es keine App gibt — Windows vor allem.
Aufbau
| Ordner | Was |
|---|---|
app/ |
Das Frontend (Vite, TypeScript) |
server/ |
Ein Server ohne Abhängigkeiten, der die Anfragen weiterreicht und die gebauten Dateien ausliefert |
frontend/ |
Die erste Fassung als einzelne Datei. Läuft, wird abgelöst. |
jellyfin-theme/ |
Ein Kleid für Jellyfins eigene Oberfläche — die kleine Lösung von vorher |
Warum ein eigener Server?
Er löst zwei Dinge, an denen die einzelne Datei scheitert, und zwar unabhängig davon, wie gut das Frontend geschrieben ist:
- Herkunft. Anfragen laufen über
/apiund damit über dieselbe Adresse wie die Seite. Kein CORS, auch nicht beim Streamen. - Klartext und Verschlüsselung. Läuft der Medienserver über
httpund die Seite überhttps, blockiert der Browser den Stream. Dagegen kann keine Zeile im Frontend etwas tun — ein Server davor schon.
Nebenbei bleibt der Zugangsschlüssel beim Server, statt im Browser zu liegen.
Betreiben
cd app && npm install && npm run build
cd ../server && FLARO_SERVER=http://jellyfin:8096 node index.js
Dann auf http://localhost:8080. Der Port lässt sich über PORT ändern.
Entwickeln
cd app && FLARO_SERVER=http://jellyfin:8096 npm run dev
Vite übernimmt dabei das Weiterreichen, der eigene Server wird nicht gebraucht.