Files
Flaro/web
ScarriffleandClaude Opus 5 637e95fbb1 Die Verwaltung zeichnete sich endlos neu
Gemessen am laufenden Server: nach dem Scan lief eine Schleife mit zwei
Abrufen je Runde, sichtbar als vier dauernd drehende Spinner.

Der Weg dahin: verfolgen() lief bei jedem Aufbau der Mediathekenzeile, sah
den Zustand finished, meldete das über geaendert(), und geaendert() war
mediathekenNeuLaden — also neu zeichnen. Der Neuaufbau startete verfolgen()
erneut, das wieder finished sah. Dass der Lauf längst vorbei war, machte
keinen Unterschied; der Zustand bleibt im Speicher stehen.

Zwei Dinge dagegen. verfolgen() meldet nur noch, wenn es selbst einen Lauf
angestossen hat — beim Aufbau zeigt es den Stand an und schweigt. Und die
Verwaltung frischt über zaehlerAuffrischen() nur noch die Seitenleiste auf
statt die ganze Seite neu zu zeichnen.

Dazu zwei Befunde aus dem Plan, die sich beim Nachsehen als falsch
erwiesen: die Takte werden sehr wohl abbestellt, dafür gibt es seit je
einen MutationObserver, und das Dashboard tauscht seinen Inhalt erst nach
dem Abruf. Geblieben ist der Spinner in den Listen, der bei jedem
Auffrischen erschien — der kommt jetzt nur noch beim ersten Aufbau.

Dazu der Zwischenspeicher für Ansichten. Der Router hängt sie aus statt
sie zu zerstören; beim Zurückkommen stehen sie sofort wieder da, mitsamt
Bildlauf, offenem Reiter und gesetzten Filtern, und laden leise nach.
Gemessen: null Abrufe und 4 von 4 Kacheln beim Zurückkommen aus der
Verwaltung. Höchstens fünf Ansichten, Verfall nach fünf Minuten,
weggeworfen bei allem, was den Bestand ändert. Detailseite und Verwaltung
sind ausgenommen — beide zeigen Laufendes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-04 12:11:06 +02:00
..

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 /api und damit über dieselbe Adresse wie die Seite. Kein CORS, auch nicht beim Streamen.
  • Klartext und Verschlüsselung. Läuft der Medienserver über http und die Seite über https, 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.