T

ScarriffleandClaude Opus 5 c681d69fcc Fünf Fehler auf einem Weg — warum nie ein Untertitel kam

Sechs Reparaturversuche haben nichts bewirkt, weil jeder an einer Stelle
ansetzte, die gar nicht die Ursache war. Eine systematische Untersuchung —
45 Hypothesen, jede von drei Skeptikern gegengeprüft — hat fünf voneinander
unabhängige Defekte auf demselben Weg gefunden. Jeder einzelne genügt.

**1. Es wurde eine Playlist bestellt, die keine Untertitelspur tragen kann.**
Jellyfins TranscodingUrl lautet `main.m3u8` — eine Media Playlist, also eine
Liste von Schnipseln. `#EXT-X-MEDIA`, die Zeile, mit der ein Server eine
Untertitelspur ankündigt, darf nach RFC 8216 nur in einer Master Playlist
stehen. Der Wechsel main→master hing aber an der Leiter, und die wird beim
Umpacken und bei jeder von Hand gewählten Stufe nicht bestellt. Ein Matroska
geht immer über das Umpacken — die halbe Sammlung konnte strukturell keine
Untertitel haben.

Der Kommentar daneben war überholt und hat den Fehler verdeckt: er stammte
aus der Zeit, als Umpacken eine fortlaufende MP4 war. Seit es über HLS läuft,
ist die Master-Liste genau richtig. Pfadwechsel und Leiter sind jetzt zwei
Fragen, nicht eine.

**2. Der lokale Server etikettierte jeden Schnipsel als video/mp4.** Auch die
WebVTT-Schnipsel der Untertitelspur. So angekündigt gehen sie bei
AVFoundation an den falschen Parser, finden keine Box, und es entsteht
lautlos keine Einblendung — die Spur steht im Blatt, ist ausgewählt, bleibt
leer. Der Vorrat behält jetzt die Sorte der Gegenstelle; die Endung ist nur
noch der Notnagel.

**3. Nach dem ersten Untertitel wählte niemand mehr etwas aus.**
`selectedSubtitleTrack` wurde beim Neuaufbau nie zurückgesetzt, und beide
Wähler prüfen genau darauf. Eine frische Engine hat aber nichts ausgewählt —
also blieb sie für den Rest des Films stumm, während das Symbol „ein" zeigte.
Auch das Nachfassen im Sekundentakt war damit stillgelegt. Die Bestellung
(`selectedSubtitleStream`) bleibt, die Merker fallen.

**4. Die Schutzmarke war nach 250 ms tot.** `restart()` setzte sie als
Allererstes — und wartete danach auf einen echten Netzaufruf mit fünf
Sekunden Zeitgrenze, bevor es den alten Ereignisstrom abbestellte. In diesem
Fenster meldete der alte Player weiter seine Stelle, und die Prüfung „sind
wir angekommen" traf sofort zu. Die Marke war gelöscht, bevor der neue Stream
bestellt war; danach setzte jede Meldung des anlaufenden Streams die Stelle
auf null, und der nächste Neuaufbau merkte sich den Filmanfang. Das war der
Sprung — und der Grund, warum mein Fix von 88ba1a5 wirkungslos blieb.

**5. Der Sprung wurde einmal versucht und nie geprüft.** Der Rückgabewert von
`seek` wurde verworfen, die gemerkte Stelle verbraucht, bevor gesprungen
wurde, und framegenaue Toleranz verlangt — in einen Stream, den der Server
gerade erst erzeugt. Jetzt bleibt die Stelle stehen, bis ein Sprung bestätigt
ist, die Toleranz liegt bei einer halben Sekunde, und jedes Wachsen des
springbaren Bereichs ist ein neuer Anlass.

Belegt statt vermutet: ein neuer Test startet den lokalen Server gegen einen
eigenen Herkunftsserver und liest die Antworten Byte für Byte — ohne Gerät,
ohne Simulator, in 0,03 Sekunden. Er hat Fehler 2 vor der Reparatur
reproduziert und danach bestätigt. Fünf weitere Tests halten Fehler 1 fest.

Zwei alte Tests hielten das fehlerhafte Verhalten fest und waren damit
mitschuldig; beide sind mitgeändert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-29 06:04:40 +02:00

docs/superpowers/specs

Entwurf für Standardsprachen der Tonspur

2026-09-27 18:59:46 +02:00

DownloadWidget

Phase 6: Live-TV, plus Live Activity für Downloads

2026-09-11 17:54:17 +02:00

Flixy

Fünf Fehler auf einem Weg — warum nie ein Untertitel kam

2026-09-29 06:04:40 +02:00

FlixyUITests

Das Qualitätsblatt hat die App angehalten

2026-09-15 21:45:09 +02:00

Packages

Fünf Fehler auf einem Weg — warum nie ein Untertitel kam

2026-09-29 06:04:40 +02:00

Tools

Mediatheken ohne bekannte Art verschwanden wortlos

2026-09-20 11:10:38 +02:00

web

„Auto" gibt nicht mehr auf, es versucht es kleiner

2026-09-27 18:30:10 +02:00

.gitignore

Phase 0: Projektgerüst, Design-Tokens und Navigation

2026-09-11 16:04:40 +02:00

project.yml

FlixyMac ist weg

2026-09-15 21:00:44 +02:00

README.md

Ein Werkzeug für die Fragen, die reines HTTP sind

2026-09-12 15:04:00 +02:00

README.md

Flixy

Ein nativer Plex-Client für iPhone und iPad — dunkel, mit ausfahrbarer Seitenleiste und Offline-Downloads.

Der Name ist ein Platzhalter. Siehe Flixy/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-flixy-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:

VLCKit ruft seinen Delegaten vom eigenen Thread, nicht über die Hauptwarteschlange. MainActor.assumeIsolated brach die App beim Drücken auf Play hart ab.
app.plex.tv/auth verknüpft den Code nicht, wenn man im Browser schon bei Plex angemeldet ist — es springt auf watch.plex.tv weiter. plex.tv/link tut es zuverlässig.
URLSessionDownloadTask gilt auch bei 404 als erfolgreich und legt die Fehlerseite als Datei ab.

Aufbau

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

xcodegen generate
open Flixy.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/FlixyKit. Das App-Target enthält nur Oberfläche und Navigation.

Modul	Aufgabe	Hängt ab von
`PlexKit`	Anmeldung, Endpunkte, Modelle. Kein SwiftUI.	—
`FlixyDesign`	Farben, Typografie, wiederkehrende Bausteine.	—
`FlixyPlayback`	Wiedergabe-Abstraktion und die Entscheidung DirectPlay/Transcode.	`PlexKit`
`FlixyDownloads`	Warteschlange, Hintergrundübertragung, Offline-Bestand.	`PlexKit`

Warum zwei Player

iOS spielt weder Matroska-Dateien noch DTS- oder TrueHD-Ton — und genau das liegt in typischen Plex-Beständen. PlaybackDecider prüft deshalb pro Datei, ob AVPlayer sie nativ öffnen kann (dann gibt es Bild-in-Bild und AirPlay gratis), und schickt sie sonst an VLCKit.

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/FlixyKit && 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/PlexKitTests/Fixtures sind von Hand geschrieben und gehören durch echte Mitschnitte ersetzt, sobald ein Server erreichbar ist — siehe das README dort.

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

Was noch am echten Server zu prüfen ist

Komprimierte Downloads. Sie laufen über den Universal-Transcoder mit protocol=http statt über die umständliche Sync-API. Offen: ob Plex eine Content-Length mitschickt (ohne sie gibt es keinen Fortschrittsbalken und kein Fortsetzen) und ob die Datei durchsuchbar ist. Original bleibt solange Voreinstellung. Siehe transcodedDownloadURL in PlexServer+Playback.swift. Ein Fehlschlag erscheint immerhin als solcher — die Plausibilitätsprüfung in DownloadCoordinator.implausibility verwirft Fehlerseiten und abgebrochene Übertragungen, statt sie als fertig zu verbuchen.
Live-TV: die Senderliste. Dass die Empfänger unter Dvr gefunden werden, ist geprüft. Ob /livetv/dvrs/{id}/channels die Sender liefert, nicht. Die Ansicht unterscheidet beide Fälle: „Kein Empfänger eingerichtet" gegen „Keine Sender" — daran ist ablesbar, wo es hakt.
App-Größe. Die iOS-Slice von VLCKit ist unstripped 239 MB. Was davon im fertigen Archiv übrig bleibt, ist noch nicht gemessen.
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)

Live-TV untersuchen, ohne zu bauen

Die Live-TV-Schnittstelle von Plex ist nirgends beschrieben, und jede Vermutung darüber ging bisher als TestFlight-Build hinaus und kam als Screenshot zurück. Irgendwann war das Upload-Kontingent des Tages aufgebraucht — für eine Frage, die keine Oberfläche braucht.

cd Packages/FlixyKit && swift run FlixyProbe

Beim ersten Lauf zeigt das Werkzeug einen Code für plex.tv/link; danach liegt der Token im Schlüsselbund dieses Rechners. Es sucht den Server, liest Senderliste und Programm und probiert das Einschalten durch — mit derselben Logik wie die App, nur in Sekunden statt in einem halben Tag.

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