ScarriffleandClaude Opus 5
c4af182d31
39,1 GB in FLARO_TRANSCODE, und das war kein Normalzustand, sondern ein
Leck: für jede Mitnahme baut der Server eine MP4 in Quellgrösse und löschte
sie nie. Die einzige Löschung, die es gab, räumte ältere Fassungen
derselben Datei weg. Stromordner verschwanden nur beim geordneten
Herunterfahren, Untertitel gar nicht.
**Zuerst: fertig heisst fertig.** ffmpeg schrieb direkt auf den Endnamen.
Nach einem harten Abbruch lag dort eine abgeschnittene Datei, `IsReady`
meldete „fertig", und sie ging so hinaus — und ein Aufräumer konnte
vollständig und abgeschnitten nicht unterscheiden. Gebaut wird jetzt unter
`.teil`, umbenannt erst nach Erfolg. Dabei muss das Format ausdrücklich
gesetzt werden: ffmpeg wählt den Muxer an der Endung und antwortet auf
`.teil` mit „Unable to choose an output format". Das hätte jedes Umpacken
zerlegt; die Prüfung hat es gefunden, bevor es jemand zu spüren bekam.
**Zwei Stufen für die Pakete.** Verwaiste gehen bedingungslos: unleserlicher
Name, fremde Bauart, kein Eintrag in der Mediathek, oder der Zeitstempel im
Namen passt nicht mehr. Der Rest fällt unter Obergrenze (20 GB) und Alter
(7 Tage), Ältestes zuerst.
Beides, und nicht eines: ein Alter allein löst den Fall nicht, denn die 39
GB waren gültige, aktuelle Dateien, jede für sich berechtigt. Eine
Obergrenze allein ist zu grob — ein Topf knapp darunter, in dem seit Wochen
nichts gebraucht wurde, besetzt ein Volume, das anderes braucht.
„Zuletzt gebraucht" ist die Änderungszeit der Paketdatei selbst, bei jeder
Auslieferung neu gestempelt. Die Zugriffszeit wäre das Naheliegende, nur
führt sie nicht jedes Dateisystem — mit `noatime` steht sie still, und der
Aufräumer hielte alles für uralt.
Ein laufender Download wird nie gelöscht: ein Benutzungszähler hält die
Datei fest, solange die Antwort läuft, dazu eine Schonfrist von 30 Minuten.
Der Zähler ist auch unter Linux nötig — der laufende Strom überlebt ein
Entfernen, die Fortsetzung einer Bereichsanfrage nicht, und der Client finge
von vorn an.
**Stromordner** werden beim Start bedingungslos geleert — nach einem Start
gibt es keine einzige Sitzung, also ist jeder Ordner verwaist. Im Betrieb
nur die ohne passende Sitzung, deren Änderungszeit älter ist als die
Geduld; das fängt auch den Fall, dass `Abraeumen` an einem IOException
scheitert und der Ordner für immer liegenbleibt.
**Untertitel** nur, wenn sie verwaist sind. Keine Obergrenze: eine .vtt ist
Kilobytes, und eine gültige wird wieder gebraucht — sie nach Platz zu
löschen hiesse, Minuten Lesearbeit gegen Megabytes zu tauschen. Eine leere
bleibt ausdrücklich liegen: sie ist das Ergebnis „diese Spur hat keinen
Text", und wer sie wegräumt, lässt bei jedem Start eine vierzig Gigabyte
grosse Datei neu durchlesen.
**Vier Anlässe, kein Dienst.** Start, vor jedem Umpacken, nach einem Scan,
auf Knopfdruck — wie alles Wiederkehrende in diesem Server. Einer zur Zeit;
wer nicht hineinkommt, geht weiter.
Gemessen am laufenden Server mit Attrappen:
vorher packages 17408 KB (4), untertitel 5 KB (3), 1 Stromordner
nachher 14 MB freigegeben, 4 Dateien
gültiges Paket blieb, verwaistes/veraltetes/Teilstück weg,
verwaiste .vtt weg, gültige blieben, Stromordner weg
Obergrenze 1 MB, Datei in der Schonfrist -> bleibt
Obergrenze 1 MB, Schonfrist vorbei -> 3072 KB freigegeben
In der Übersicht steht die Belegung je Unterordner mit Dateizahl und
daneben „Jetzt aufräumen"; die drei Zahlen stehen unter Wiedergabe, wo
Transcoder-Stufe und Schwellen schon stehen — der Kratzplatz ist, was die
Wiedergabe hinterlässt.
714 Tests grün, davon 36 neue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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:
URLSessionDownloadTaskgilt 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 generateschreibtproject.pbxprojneu. 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.ymlsich ä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
- Komprimierte Downloads. Offen: ob der Server bei den umgerechneten
Stufen eine
Content-Lengthmitschickt. 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 inDownloadCoordinator.implausibilityverwirft Fehlerseiten und abgerissene Übertragungen, statt sie als fertig zu verbuchen. - Sprachkennungen nach dem Umpacken. Jellyfin verliert sie: alle Spuren
kommen als
undan, obwohl die Quelle sie führt. Am fertigen Download gemessen, Ursache noch offen. - 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.