ScarriffleandClaude Opus 5
767491ef03
Die Markensuche lief stundenlang über 95 Serien, 4213 Folgen und 453
Filme und schrieb dabei fünf Zeilen, in denen Kennungen standen statt
Namen. „Markenerkennung für 4f3a…: 12 Marken." beantwortet keine der
Fragen, die in den letzten Tagen tatsächlich aufkamen — welche Staffel
nichts bekommen hat, warum, und ob die Serie überhaupt dran war.
Jetzt nennt jede Zeile den Titel, und es gibt eine je Serie, je Staffel
und je Folge:
„Biohackers": 2 Staffel(n), 18 Folge(n).
„Biohackers", Staffel 2: Vorspann in 8 von 8 Folge(n), Abspann in 1 von 8.
Biohackers S02E01 · Neuanfang: Vorspann 0:31–1:24, Abspann ab 41:12 (über das Bild).
Biohackers S02E07 · Letzte Fahrt: Vorspann 0:31–1:24, kein Abspann.
„Biohackers" fertig: 14 Marke(n).
Die Folgenzeilen werden **aus der Datenbank gelesen, nicht mitgezählt**:
so steht dort, was danach wirklich an der Folge hängt, und nicht, was
dieser eine Lauf geschrieben hat. Nur das beantwortet „warum kommt bei
dieser Folge kein Knopf?".
**Drei Gründe statt eines `false`.** `FilmAsync` gab für „keine Datei",
„schon durchsucht" und „nichts gefunden" dasselbe zurück, und von aussen
waren sie nicht zu unterscheiden. Jetzt sagt jeder seinen Namen.
**Und eine Live-Zeile bei der Mediathek**, wie der Scan sie hat. Sie
benutzt denselben Mechanismus — `Scanschritt` mit einer neuen Phase,
derselbe Endpunkt, ein eigenes Feld. Ein eigenes, weil der Scan sich auf
„fertig" setzt, sobald er die Markensuche angestossen hat; in sein Feld
geschrieben sähe er wieder laufend aus.
**Zwei Fehler sind dabei herausgefallen.** In `NachScanAsync` stand
`if (serien.Count == 0) return;` vor dem Filmteil — eine reine
Filmmediathek bekam nach einem Scan also nie eine Abspannsuche. Und die
fpcalc-Prüfung stand ganz oben und galt für beides, obwohl der Bildweg
fpcalc gar nicht braucht: ohne fpcalc fand der Server keinen einzigen
Filmabspann.
Dazu ein Suchfeld im Protokoll und tausend Anfangszeilen statt
dreihundert. Ohne das wäre eine Zeile je Folge keine Auskunft, sondern
eine Mauer — genau der Fall, gegen den sich `ScanCoordinator` für den
Scan schon einmal entschieden hat.
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.