Deine Angabe war der Schlüssel: du hast **mitten im Film die Tonspur umgeschaltet**. Dabei baut der Spieler den Strom an der aktuellen Stelle neu auf, und damit greift der Sprung — den ich gestern nur mit Spielzeugdateien gemessen hatte. Also eine Datei gebaut, die einem Film gleicht: 23,976 Bilder je Sekunde, Schlüsselbild alle fünf Sekunden, zwei Tonspuren, Deutsch als Stereo-AAC und Englisch als 5.1 in EAC3. Gemessen, erster Zeitstempel je Spur: | | Bild ab | Ton ab | |---|---|---| | Spur 2, ab Sekunde 0 | 0,021 | 0,000 | | Spur 2, ab 17 (mitten in der Bildgruppe) | 0,000 | **1,964** | | Spur 2, ab 15 (knapp vor dem Schlüsselbild) | 0,000 | **4,969** | Fast fünf Sekunden Bild ohne Ton. Zueinander sind beide dabei richtig getaktet — aber eine solche Lücke am Anfang darf jeder Spieler deuten, wie er will, und hls.js schiebt den Ton dann nach vorn. Genau das hast du gehört. Die Rundung auf das Schlüsselbild, die seit E8GSRE drin ist, nimmt das weg: dieselbe Datei, Sprung auf 17, gerundet auf 15,015 — **Bild ab 0,000, Ton ab 0,004**. Du läufst noch auf 5YZ63F; deshalb steht im Protokoll auch keine ffmpeg-Warnung, die gibt es erst ab E8GSRE. **Die Tonspur lässt sich jetzt vor dem Start wählen.** Auf der Detailseite steht neben „Abspielen" ein Knopf „Ton: Deutsch"; das Menü zeigt alle Spuren der Datei. Gemerkt wird dabei die **Sprache**, nicht die Spurnummer — welche Nummer Englisch trägt, ist von Film zu Film verschieden, dass du Englisch willst, ist es nicht. Beim nächsten Film steht die passende Spur damit schon da, und das Umschalten mitten im Film entfällt. Wer doch im Spieler wechselt, ändert dieselbe Merkstelle. **Und ein Fehler aus deinem Protokoll**, der nichts damit zu tun hat: „UNIQUE constraint failed: Sehtage.UserId, Sehtage.Tag, Sehtage.MovieId". Das ist ein Wettlauf im Sehprotokoll von vorgestern — der Spieler meldet alle zehn Sekunden, ein Sprung meldet sofort, und zwei Meldungen können sich überholen. Dann fanden beide keine Zeile, beide legten eine an. Jetzt wird in der Datenbank hochgezählt statt im Speicher, und wer dabei zu spät kommt, zählt beim zweiten Versuch mit. Mit Test. 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.