ScarriffleandClaude Opus 5 c2fd2a86fd Einmal aus der Datei holen, nicht bei jedem Abruf
„Diese Untertitelspur liess sich nicht laden", und auf der zweiten Spur kam
gar nichts. Nicht das Format war schuld und auch nicht das Verschieben,
sondern die Zeit: jeder Abruf startete ffmpeg, ffmpeg musste die ganze
Datei durchlesen, und nach dreissig Sekunden wurde abgebrochen. An einem
Prüffilm von fünfzehn Megabyte fällt das nie auf; bei einem Dreistünder auf
einem NAS reicht es nie.

Schlimmer wurde es durch meine eigene Korrektur von gestern: seit die
Adresse den Einstiegspunkt mitführt (`?ab=`), ändert sie sich bei jedem
Sprung — der Browser konnte nichts mehr aus seinem Zwischenspeicher nehmen,
und jeder Sprung stiess einen neuen Durchlauf an.

Jetzt:

- Ein ffmpeg-Durchlauf holt alle Textspuren auf einmal. Das Lesen der Datei
  ist der teure Teil und wird nicht mehr je Spur bezahlt.
- Das Ergebnis bleibt liegen, ungeschoben; das Verschieben ist eine
  Zeilenersetzung und kostet nichts. Gemessen: erster Abruf 0,42 s, jeder
  weitere 2 bis 3 ms — und der zweite Sprung in derselben Datei trifft
  dieselbe Ablage statt eines neuen Durchlaufs.
- Angestossen wird beim Start des Stroms, nicht erst beim Einschalten. Wer
  nach einer halben Stunde Untertitel will, wartet dann gar nicht.
- Geschrieben wird unter `.teil` und erst danach umbenannt. Eine
  abgebrochene Datei am richtigen Namen gälte sonst für immer als fertig.
- Die Geduld steigt von 30 Sekunden auf 30 Minuten. Sie ist jetzt eine
  Obergrenze gegen einen hängenden Prozess, keine Wartezeit mehr.

Und der Spieler kann endlich unterscheiden, was los ist. Ein `<track>`
meldet jeden Misserfolg gleich — „es gibt sie nicht", „sie enthält keinen
Text" und „der Server holt sie gerade" sahen identisch aus. Geholt wird
deshalb selbst, mit Token statt Keks (gemessen: ohne Keks kam jeder Abruf
mit 401 zurück, ohne dass irgendwo etwas stand), und bei 503 fragt der
Spieler nach, statt aufzugeben. Der Text geht als Blob an den `<track>` —
dieselbe Anzeige, ein ehrlicher Weg dahin.

Dazu eine Unsauberkeit im Verschieben: die Trennzeile eines weggefallenen
Blocks blieb stehen. Gemessen am echten Film 52 Leerzeilen vor dem ersten
Satz.

Geprüft im Spieler, kalter Vorrat, Einstieg bei Sekunde 500: Blob am
`<track>`, zehn Einblendungen, die erste bei 0 bis 3 s mit „Deutsch bei
500 s".

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

Flaro

Ein nativer Jellyfin-Client für iPhone, iPad, Mac und Apple TV — dunkel, mit ausfahrbarer Seitenleiste und Offline-Downloads.

Der Name ist ein Platzhalter. Siehe Flaro/Branding.swift.

Stand

Alle sechs Phasen sind gebaut. Anmeldung, Blättern und Wiedergabe laufen am echten Server; der Rest ist unterschiedlich weit geprüft.

Der Fahrplan steht in docs/superpowers/specs/2026-09-11-flaro-design.md.

Phase Inhalt Stand
0 Projektgerüst, Design-Tokens, Navigation ✅
1 Anmeldung, Bibliothek, DirectPlay ✅ am Server geprüft, iPhone und iPad
2 Transcoding, adaptive Bitrate, Spuren, Sync ✅ Wiedergabe geprüft; Transcoding selbst noch nicht erzwungen
3 Download-Engine und Offline-Wiedergabe ⚠️ Downloads starten, Offline-Wiedergabe noch nicht bestätigt
4 Download-Intelligenz ⚠️ komprimierte Downloads ungeprüft
5 Feinschliff und Personalisierung ✅ gebaut, teilweise geprüft
6 Live-TV mit EPG ⚠️ Empfänger werden gefunden, Sender noch nicht bestätigt

„Ungeprüft" heißt: die Logik ist von Tests abgedeckt, an einem echten Bestand aber noch nicht gesehen.

Was der Praxistest gelehrt hat

Drei Fehler, die kein Test gefunden hätte, weil sie in Annahmen über fremde Bibliotheken steckten — sie stehen als Warnung im jeweiligen Quelltext:

  • URLSessionDownloadTask gilt auch bei 404 als erfolgreich und legt die Fehlerseite als Datei ab.
  • Hintergrund-Sitzungen setzen abgerissene Übertragungen still bei null fort, ohne es zu melden — gemessen wurden sieben Anläufe hintereinander.
  • Jellyfins Transcode-Endpunkt bildet eine Tonspur je Sitzung ab. Ein Download kommt deshalb einspurig an, und welche Spur es ist, entscheidet sich am Server. Der Grund, warum beim Herunterladen gefragt wird.

Aufbau

Die Xcode-Projektdatei wird aus project.yml erzeugt und ist nicht eingecheckt — das erspart Konflikte in der pbxproj.

xcodegen generate
open Flaro.xcodeproj

Wichtig: Xcode vorher beenden.

xcodegen generate schreibt project.pbxproj neu. Ein geöffnetes Xcode liest das nicht nach — es hält seinen eigenen Stand im Speicher und überschreibt die frisch erzeugte Datei beim nächsten Sichern wieder. Neue Dateien fehlen dann im Build, ohne dass irgendwo ein Fehler auftaucht.

Das ist der Preis dafür, die Projektdatei aus Git herauszuhalten. Immer wenn Dateien dazukommen oder project.yml sich ändert: Xcode mit ⌘Q beenden, xcodegen generate, neu öffnen.

Ob der Build aktuell ist, steht in der App unter Einstellungen → Diagnose als Build-Datum.

Der Code liegt zum größten Teil in lokalen Packages unter Packages/FlaroKit. Das App-Target enthält nur Oberfläche und Navigation.

Modul Aufgabe Hängt ab von
MediaKit Die serverneutrale Grundschicht: Typen und Rechnungen, die für jeden Server gelten. —
JellyfinKit Anmeldung, Endpunkte, Modelle. Kein SwiftUI. MediaKit
FlaroDesign Farben, Typografie, wiederkehrende Bausteine. —
FlaroPlayback Wiedergabe-Abstraktion und die Entscheidung DirectPlay/Umpacken/Transcode. MediaKit
FlaroDownloads Warteschlange, Hintergrundübertragung, Offline-Bestand. MediaKit

Warum umgepackt wird

iOS spielt weder Matroska-Dateien noch DTS- oder TrueHD-Ton — und genau das liegt in typischen Beständen. PlaybackDecider prüft deshalb pro Datei, ob AVPlayer sie nativ öffnen kann, und lässt sie sonst vom Server umpacken: Bild und Ton wandern unverändert in eine MP4, nur die Schachtel wechselt. Das kostet den Server fast nichts — und die Wiedergabe bleibt im Systemplayer, also mit Bild-in-Bild, AirPlay und Systembedienung.

Ein zweiter Player stand hier einmal. Er konnte zwar alles öffnen, brachte aber keines dieser drei Dinge mit.

Ab Phase 2 kommt der dritte Weg dazu: Server-Transcoding. Dafür ist genau eine Funktion zu erweitern — PlaybackDecider.decide(media:part:policy:). Die Oberfläche bleibt unberührt.

Tests

Die Logik-Tests laufen ohne Simulator, deshalb in Sekunden:

cd Packages/FlaroKit && swift test

Die wichtigste Testdatei ist PlaybackDeciderTests — sie hält fest, welche Datei auf welchem Weg landet, und schlägt an, sobald jemand DeviceCapabilities anfasst.

Die Antwort-Vorlagen unter Tests/JellyfinKitTests/Fixtures sind echte Mitschnitte vom Server.

Die Oberfläche wird von Hand im Simulator geprüft.

Was noch am echten Server zu prüfen ist

  1. Komprimierte Downloads. Offen: ob der Server bei den umgerechneten Stufen eine Content-Length mitschickt. Ohne sie greift beim Prüfen auf Vollständigkeit nur die weiche Regel, und ein Fortschrittsbalken ist eine Schätzung. Ein Fehlschlag erscheint immerhin als solcher — die Plausibilitätsprüfung in DownloadCoordinator.implausibility verwirft Fehlerseiten und abgerissene Übertragungen, statt sie als fertig zu verbuchen.
  2. Sprachkennungen nach dem Umpacken. Jellyfin verliert sie: alle Spuren kommen als und an, obwohl die Quelle sie führt. Am fertigen Download gemessen, Ursache noch offen.
  3. Große Dateien im Hintergrund. Das Verhalten mit einem 40-GB-Remux — vor allem Pausieren und Fortsetzen — ist nur gegen Testdaten geprüft.

Voraussetzungen

  • Xcode 26 oder neuer
  • iOS 26.0 auf dem Zielgerät
  • XcodeGen (brew install xcodegen)

Fragen stellen, ohne zu bauen

Jede Vermutung über die Schnittstelle eines Servers ging bisher als TestFlight-Build hinaus und kam einen halben Tag später als Screenshot zurück. Irgendwann war das Upload-Kontingent des Tages aufgebraucht — für eine Frage, die keine Oberfläche braucht.

cd Packages/FlaroKit
swift run FlaroProbe --jellyfin <host>          # Welche Leiter baut der Server?
swift run FlaroProbe --spuren <host> <suche>    # Welche Tonspuren hat ein Titel?
swift run FlaroProbe --playlist <url>           # Was steht in dieser HLS-Leiter?

--jellyfin und --spuren fragen nach Benutzername und Passwort und legen den Token im Schlüsselbund dieses Rechners ab. --playlist braucht gar keine Anmeldung.

Ausgegeben werden Pfade, Kennungen und die Antworten des Servers. Keine vollständigen Adressen, also auch kein Token.

S
Description
No description provided
Readme GPL-2.0
13 MiB
Languages
C# 43.1%
Swift 38.4%
TypeScript 12.5%
CSS 2.5%
HTML 2.2%
Other 1.3%