189 Commits

Include renames

Author	SHA1	Message	Date
ScarriffleandClaude Opus 5	afa78f9ee0	Ein Knopf, von dem niemand weiss, dass es ihn gibt, ist keiner ... „Intro überspringen" lag im Web in der Bedienleiste und verschwand mit ihr. Am Fernseher sieht man die Leiste gar nicht — der Knopf war also da und trotzdem unsichtbar. Jetzt liegt er als eigene Schicht über dem Bild und bleibt stehen, solange die Marke läuft. **Im Abspann ist „überspringen" ohnehin die falsche Frage.** Was man dort will, ist die nächste Folge; ans Ende dieser zu springen bringt niemanden weiter. Gibt es eine, heisst der Knopf jetzt so — im Web wie in der App, und in der App nicht mehr erst, wenn alles durchgelaufen ist. Bei einem Film gibt es nichts danach: dort heisst „Abspann überspringen" jetzt wirklich Schluss, statt auf ein stehendes Bild zu spulen und den Spieler offen zu lassen. Dazu der Titel über dem Spieler. Dort stand bei einer Folge „S1 E6" und bei einer aus der Detailseite gestarteten sogar nur „Wiedergabe". Auf einer Kachel ist die Kurzform richtig, dort zählt jeder Buchstabe; über dem Spieler steht eine Zeile in einer leeren Fläche. Jetzt steht da „Küstenwache · Staffel 1 · Folge 6 · Der Nebel kommt". In der App hiess es „Episode" statt „Folge" — das eine Wort, das sonst nirgends steht. Und drei Prüfungen für die Marken auf dem Weg in die App: aus einer Serverantwort mit Vorspann und Abspann werden zwei Marken an der richtigen Stelle. Die Übersetzung war nicht der Grund, warum der Knopf dort fehlte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-13 15:35:59 +02:00
ScarriffleandClaude Opus 5	7673c73757	Vier Sekunden, die ffprobe zu früh aufhörte zu lesen ... Die Untertitel kamen vier Sekunden zu spät. Nicht an ihnen lag es: der Server meldete dem Spieler einen Anfang, der vor dem lag, an dem der Strom wirklich begann, und genau diese Differenz landet eins zu eins im Versatz. Die Schlüsselbildsuche las mit `-read_intervals` bis eine halbe Sekunde hinter den Wunsch. ffprobe bricht am Ende eines Fensters auf Paketebene ab — das letzte Schlüsselbild darin kam regelmässig gar nicht mehr heraus, und die Suche gab das davor zurück. Bei Bildgruppen von vier Sekunden sind das vier Sekunden. Nachgemessen gegen die Stelle, an der ffmpeg tatsächlich anfängt, an einer Datei mit Schlüsselbildern alle vier Sekunden: Wunsch Suche (0,5 s) ffmpeg Abweichung 52,0 48 52,0 −4,0 73,3 68 72,0 −4,0 100,2 96 100,0 −4,0 Mit zehn Sekunden Nachlauf lag dieselbe Messung bei allen sieben Werten auf 0,000. Was über den Wunsch hinausgelesen wird, verwirft die Filterung ohnehin. Die Prüfung vergleicht nicht gegen eine erwartete Zahl, sondern gegen ffmpeg selbst — mit dem alten Wert fällt sie um. Dazu der Filmteil der Abspannerkennung: `Abspannkante` als reine Rechnung mit elf Prüfungen, `Bildabtaster` über ffmpeg, Marken auch an Filmen, Knöpfe zum Suchen und Verwerfen auf der Filmseite. An einer erzeugten Datei trifft die Kante auf vier Sekunden genau. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-13 06:42:16 +02:00
ScarriffleandClaude Opus 5	1d70be0f99	Fünf Aufmacher je Titel, und der Abspann zählt als Schluss ... **Der Aufmacher darf wechseln.** Bisher hing hinter jedem Titel genau ein Hintergrundbild, und das Karussell war nach einer Woche ein Standbild. Jetzt lassen sich bis zu fünf Aufnahmen aussuchen — im Bilderdialog unter einem vierten Reiter, gespeist aus denselben Hintergründen. Welches gerade gilt, entscheidet der Server aus Uhrzeit und Kennung: alle fünf Stunden ein anderes, überall dasselbe — im Web, in der App, nach einem Neustart. Ein Zufall je Abruf hiesse, dass das Bild beim Blättern springt; eine gespeicherte Wahl hiesse einen Schreibvorgang je Titel und Fenster. Die Kennung geht mit in die Rechnung, damit nicht alle Titel im selben Augenblick umschalten. Plakat und Hintergrund bleiben unberührt. Sie stehen hinter Kacheln und Kopfzeilen, und dort soll nichts wechseln. **Und der Abspann zählt als Schluss.** Eine Serie hängt sechs Minuten Abspann an eine Folge von fünfundvierzig; neunzig Prozent liegen dann mittendrin, und die Folge gilt erst als gesehen, wenn man ihn sich ganz ansieht. Die Schwelle herunterzudrehen hiesse, jeden anderen Titel zu früh abzuhaken. Der erkannte Abspann ist die genauere Antwort auf dieselbe Frage — er zieht die Schwelle nach vorn, nie nach hinten. Dazu der Verlauf über dem Aufmacher: er war immer noch zu dunkel. Jetzt trägt der Schattenwurf der Schrift, was vorher eine Decke über dem ganzen Bild tat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 21:44:43 +02:00
ScarriffleandClaude Opus 5	8cf2118723	Vorspann und Abspann — erkannt, abgelegt, überspringbar ... Beides mit derselben Rechnung, nur in einem anderen Fenster: vorn die ersten fünfzehn Minuten, hinten die letzten zehn. Was `Tonabgleich` findet, hängt allein daran, welchen Ausschnitt man ihm gibt — eine zweite Erkennung für den Abspann wäre dieselbe Suche ein zweites Mal. Je Staffel verglichen, nicht je Serie: Serien wechseln ihren Vorspann zwischen Staffeln, und über alle hinweg fände man nichts oder das Falsche. Gefundenes über fünf Minuten wird verworfen — zwei Folgen, die dieselbe Datei tragen, teilen vierzig, und darüber stünde sonst ein Überspringen-Knopf. Der Lauf geht auf Zuruf, nicht bei jedem Scan: er liest von jeder Folge ein Stück Ton und dauert Minuten. Der Knopf dafür steht auf der Serienseite, bei den Verwalterknöpfen. Die Marken gehen im Folgenvertrag mit — als „intro" und „credits", die Wörter, die die Apps von Jellyfin her ohnehin kennen. In der App zeichnet sie der vorhandene Überspringen-Knopf, der bisher nie etwas zu tun hatte; im Web ist er neu, rechtsbündig über der Zeitleiste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 21:28:36 +02:00
ScarriffleandClaude Opus 5	acba683c94	Eine Folge weiter, eine zurück — ohne den Spieler zu verlassen ... Wer eine Serie schaut, will blättern können. Bisher gab es genau einen Knopf dafür, und der erschien erst am Ende: „Nächste Folge", wenn der Abspann durchgelaufen war. Zurück ging gar nicht — nur über die Serienseite, und die beendet die Wiedergabe. Jetzt stehen beide Knöpfe in der Bedienleiste, in der App wie im Web, links und rechts vom Abspielknopf. Nur bei Serien: bei einem Film antwortet der Server mit 404, bei der letzten Folge mit 204, und beides heisst hier „kein Knopf". Sie erscheinen also von selbst nur dort, wo sie etwas tun. Der Server kannte nur den Weg vorwärts. Jetzt gibt es `/previous` daneben, und beide Richtungen kommen aus derselben Rechnung — als zwei Endpunkte abgeschrieben liefen sie auseinander, sobald einer etwas dazubekommt. Jellyfin hat kein Gegenstück zu „NextUp"; dort entsteht die vorige Folge aus der Folgenliste der Serie. Beim Wechsel gilt weiter, was für die Serie an Sprache eingestellt ist. Ohne das spränge die nächste Folge auf die erste Tonspur der Datei zurück — bei deutschen Veröffentlichungen also auf Deutsch, mitten in einer Serie, die man im Original schaut. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 21:11:09 +02:00
ScarriffleandClaude Opus 5	5a0f2bf07f	Eine Prüfung dafür, dass eine Datei auch ein Bild sein darf ... Der Lader gab bei jeder `file:`-Adresse `nil` zurück, und nichts hätte das gemeldet. Drei Zeilen Prüfung: ein PNG auf der Platte kommt an, eine fehlende Datei nicht, und Text ist kein Bild. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 20:28:14 +02:00
ScarriffleandClaude Opus 5	79d7d04583	Ein Download sah aus wie eine Videodatei, nicht wie ein Film ... Vier Dinge, die beim Ausprobieren auffielen. **Die Plakate blieben grau.** Sie lagen auf der Platte, der Lader wollte sie aber nicht: er verlangte von jeder Antwort eine HTTPURLResponse, und eine Datei antwortet nicht so. Jede lokale Adresse kam als `nil` zurück. **Eine Serie hatte ohnehin nie ein Plakat.** Heruntergeladen wird nie die Serie, nur ihre Folgen — und deren Bild ist das Szenenbild, quer. Jetzt kommt das Serienplakat unter dem Serienschlüssel mit und geht mit der letzten Folge wieder. **Zwanzig Folgen waren zwanzig Kacheln.** Jetzt steht die Serie einmal da, darunter wie viele Folgen bereitliegen; welche genau, zeigt ihre Seite — auch ohne Server, dann aus dem, was auf dem Gerät liegt. **Das Bild wurde schwarz, sobald jemand auf „Bildfüllend" wechselte.** Daran war ein eigener ViewModifier schuld, der zwischen `ignoresSafeArea()` und gar nichts umschaltete. Genau das ist in SwiftUI ein Zweig: der Baum darunter wurde neu gebaut, die Bildebene mit ihm. `edges: []` ignoriert nichts und bleibt doch derselbe Modifikator. Dazu „Als Nächstes": die Reihe begann am Anfang der Serie statt dort, wo der Benutzer steht. Wer bei Folge 2 war und Folge 1 nie abgehakt hatte, bekam Folge 1 vorgeschlagen — und das Abhaken half nicht, weil die Kachel sich nur selbst einen Haken malte, statt zu verschwinden. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 20:20:27 +02:00
ScarriffleandClaude Opus 5	8f0568cb6c	Ohne Server stand man vor der Tür, mit dem Film in der Tasche ... Fiel der Server aus, endete der Start bei einem Fehlerbildschirm mit zwei Knöpfen: „Erneut versuchen" und „Abmelden". Beide nützen im Flugzeug nichts — und dahinter lagen die Dateien, die man genau für diesen Fall heruntergeladen hatte. Jetzt geht die App trotzdem auf: Token und Konto liegen auf dem Gerät, die Mediathekenliste auch, und die Startseite kommt neuerdings aus demselben Speicher. Oben die Downloads, darunter der Stand vom letzten Mal, ausgegraut, mit einem Satz, der sagt warum. Die Detailseite nimmt den Titel vom Gerät, wenn der Server schweigt, und der Abspielknopf bleibt an, weil die Datei ja da ist. Und was man offline geschaut hat, zählt: Fortschritt, den der Server nicht annimmt, wird zurückgelegt und nachgereicht, sobald er wieder antwortet. Dafür sagt `reportProgress` jetzt, ob die Meldung ankam. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 19:41:22 +02:00
ScarriffleandClaude Opus 5	77593105de	Heruntergeladenes lag auf dem Gerät und war nirgends zu sehen ... Downloads gab es nur im Downloads-Bereich. Wer wissen wollte, was im Flugzeug läuft, musste zwei Listen vergleichen: die Mediathek und die Downloads. Jetzt sind sie eine Reihe auf der Startseite, tragen in jeder Kachel eine Marke, und in der Mediathek gibt es „Nur Heruntergeladene" — der Filter fragt den Server gar nicht erst, weil der nicht weiss, was auf diesem Gerät liegt. Dabei kam heraus, dass Downloads nie ein Bild mitbrachten: der Dateiname dafür stand im Modell, gesetzt hat ihn niemand. Neue holen es mit, alten wird es beim nächsten Start nachgereicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-12 19:28:45 +02:00
ScarriffleandClaude Opus 5	0a394b9b3b	„Wartet" für immer, obwohl der Server längst fertig war ... Der Eintrag ging nach einer 202 zurück auf „wartet" und rief danach `resume`. Das nimmt aber nur auf, was **angehalten oder gescheitert** ist — ein wartender lief in die Schutzklausel und kam nie wieder heraus. Im Protokoll packte ffmpeg um, in der App stand „wartet", und dazwischen lag nichts. Jetzt wird die Warteschlange abgearbeitet statt ein einzelner Eintrag aufgenommen; „wartet" steht darin. Dazu zwei Dinge, um die du gebeten hast: **Das Protokoll liest sich wie eine Kommandozeile.** Älteste Zeile oben, neueste unten, die Ansicht steht am Ende. Mitgeschoben wird nur, wenn man unten steht — wer hochgescrollt hat, liest etwas, und ihn bei jeder neuen Zeile ans Ende zu reissen wäre, als nähme man ihm die Seite aus der Hand. **Ein Tipp auf eine Kachel führt auf die Detailseite**, am Telefon wie am iPad wie am Mac. Nur in „Weiterschauen" spielt er ab: dort steht der Titel, *weil* man ihn angefangen hat. Vorher war es umgekehrt, mit dem Argument „wer eine Kachel antippt, weiss schon, was er sehen will". Im Gebrauch stimmte das nicht — wer nachsehen wollte, wie viele Staffeln eine Serie hat, bekam den Film. Ein Umweg von einem Schritt ist ärgerlich; eine Wiedergabe, die man nicht wollte, ist schlimmer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-11 20:56:39 +02:00
ScarriffleandClaude Opus 5	a44d55e71c	163 Byte als Film verbucht, in einer Sekunde heruntergeladen ... Muss der Server eine Datei umpacken, antwortet er mit **202** und einem kurzen Text: noch nicht, komm wieder. Die Prüfung im Download verwarf alles ausserhalb von 200 bis 299 — und 202 liegt mittendrin. Der Antworttext lag danach als Film auf dem Gerät. Jetzt ist 202 ein eigener Fall: der Eintrag geht zurück in die Warteschlange und fragt alle fünfzehn Sekunden erneut, bis zu fünf Minuten lang. Es ist nichts schiefgegangen, es ist nur noch nicht fertig — und im Sekundentakt nachzufragen hiesse, dieselbe Datei hundertmal anzufangen und wegzuwerfen. Gezählt wird im Arbeitsspeicher, nicht im Eintrag: nach einem Neustart beginnt das Zählen von vorn, und das ist richtig — der Server hat inzwischen vermutlich fertig gepackt. Dazu, aus derselben Meldung: bei 21∶9 auf einem Telefon reichte das Bild hinter die Dynamic Island. Im Vollbild bleibt das so — wer es wählt, hat sich fürs Beschneiden entschieden. Im normalen Modus nicht mehr: dort ist der Anspruch gerade, dass nichts fehlt, und dann darf auch nichts verdeckt sein. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-11 20:33:32 +02:00
ScarriffleandClaude Opus 5	94458ef41c	Fünf Knöpfe in einer Reihe wurden auf dem Telefon zu Säulen ... In einem `HStack` teilen sich die Knöpfe die Breite. Abspielen, Von vorn, Herunterladen und zwei Sprachknöpfe passten auf einem Telefon nicht nebeneinander — heraus kamen Säulen aus einzelnen Buchstaben, senkrecht untereinander. Lesbar war nichts mehr; angetippt hätte man trotzdem das Richtige. `Flusszeile` bricht um, statt zu quetschen: was nicht mehr hinpasst, kommt in die nächste Zeile. Zwei Zeilen sind kein Mangel, sie sind, was dort hinpasst — und ein Knopf, der auf schmalen Geräten verschwindet, wäre eine zweite Oberfläche, die gepflegt werden will. Kein `ViewThatFits`: das wählt zwischen fertigen Entwürfen, und die müsste man für jede Zahl von Knöpfen von Hand hinschreiben. Hier wird gerechnet. Dazu bleibt die Beschriftung eines Sprachknopfs einzeilig. Umbrochen wird die Reihe, nicht das Wort darin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 23:20:57 +02:00
ScarriffleandClaude Opus 5	84612335ec	Sprachwahl in der App — bei Serien und bei Filmen ... Auf der Serienseite stand ein Menü für den Ton, gefüllt mit zwanzig Sprachen, von denen die Serie zwei hatte. Für Untertitel gab es keines, und auf der Filmseite überhaupt nichts. Jetzt beides an beiden Orten, und zwar nur mit dem, was es wirklich gibt: Bei einer **Serie** über den neuen Endpunkt — die Schnittmenge über alle Folgen. Was dadurch wegfällt, steht als Satz darunter, sonst sähe eine gekürzte Liste aus wie die ganze Wahrheit. Bei einem **Film** aus den Spuren der Datei. Kein Serverweg nötig: dort ist die Datei der Titel, und ihre Spuren stehen in der Antwort, die die Seite ohnehin geholt hat. Ton und Untertitel teilen sich einen Typ. Sie unterscheiden sich in genau zwei Punkten — woher der Wert kommt und ob es „Keine" gibt; ein zweiter Typ wäre dieselbe Datei mit zwei geänderten Zeilen. „Keine" gibt es nur beim Untertitel: ein Film ohne Tonspur ist kein Wunsch, sondern ein Fehler. Die Untertitelsprache liegt je Titel, in einem Topf für Serien und Filme — eine Filmkennung kollidiert mit keiner Serie, und zwei Wörterbücher für dieselbe Frage liefen auseinander. Der Spieler liest sie jetzt: vorher kannte er nur die allgemeine, und eine Serie im Original mit deutschen Untertiteln liess sich nicht einstellen, ohne sie überall einzuschalten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 21:56:15 +02:00
ScarriffleandClaude Opus 5	693a6cc867	Cookie heisst Cookie ... „Keks", „Keksglas", „Kekse" — eingedeutscht, wo es nichts zu verdeutschen gibt. Ein Cookie ist ein Cookie; wer danach sucht, sucht nicht nach Keksen, und wer den Quelltext liest, liest daneben die Schnittstelle, in der es `HTTPCookieStorage` heisst. Betrifft Kommentare und Prüfungsnamen, kein Verhalten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 20:42:29 +02:00
ScarriffleandClaude Opus 5	f789c40594	Der Vorrat holte unangemeldet, und das stand im Protokoll ... 20:32:40 Umpacken … Vorbereitung 3203 ms 20:32:40 FlaroToken was challenged 20:32:52 Umkodieren … 0 ms 20:32:55 erstes Stück nach 2750 ms Einmal je Wiedergabe eine abgewiesene Anfrage, gefolgt von zwölf Sekunden Stille und einer zweiten Bestellung. Die zwölf Sekunden sind AVPlayer, der auf etwas wartet, das nie kommt. Der Vorrat, der dem Spieler die Schnipsel voraushält, benutzt eine flüchtige URLSession — und die bringt ihren eigenen, leeren Keksspeicher mit. Jede Anfrage von dort ging unangemeldet hinaus. Bei Jellyfin fiel das nie auf, weil der Schlüssel dort in der Adresse steht; Flaro meldet über ein Keks an. Und bisher kam der Vorrat bei Flaro nie zum Zug: er springt nur bei einer Abspielliste an, und die App hat bis gestern eine fertige Datei abgespielt. Dass die zweite Bestellung lief, passt dazu: nach dem Fehlschlag gibt der Vorrat auf, und der Spieler holt unmittelbar vom Server — mit dem Keks, den er selbst hat. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 20:35:37 +02:00
ScarriffleandClaude Opus 5	1bcf6f12e5	Die App wartete auf eine fertige Datei, statt zu streamen ... Gleichzeitig im Web und in der App auf Abspielen getippt: das Web lief, die App lud dreissig Sekunden. Das war keine Ladezeit, sondern die Zeit, die der Server braucht, um den ganzen Film einmal durchzuschreiben. `preparePlayback` kannte nur `/files/{id}/download`. Muss die Datei umgepackt werden, fragte es im Sekundentakt nach, bis die vollständige MP4 auf der Platte lag — Grenze zehn Minuten. Der Endpunkt, den das Web benutzt, ist am Server längst da; die App wusste nur nichts davon. Jetzt zuerst `/files/{id}/stream`. Das erste Stück ist beim Umpacken in deutlich unter einer Sekunde da. Der alte Weg bleibt als Rückfall: er ist langsam, kommt aber ohne Sitzung aus, und eine späte Wiedergabe ist besser als keine. **Der Strom beginnt dort, wo man weiterschauen wollte**, und zählt trotzdem ab null. Ohne das mitzurechnen stünde bei „Fortsetzen ab 1:32" eine Null auf der Uhr — und genau die ginge als Fortschritt an den Server. Also: die Zeit der Engine plus Vorlauf ist die Zeit des Films, und der Spieler springt nicht noch einmal dorthin, wo der Server schon steht. **Ein Sprung aus dem Strom heraus baut ihn neu auf.** Die Abspielliste wächst von der Einstiegsstelle vorwärts; davor und dahinter gibt es nichts, und ein Sprung ins Leere liesse den Spieler mit einem Kreisel stehen. Innerhalb des Erzeugten springt er weiterhin selbst — dafür eine neue Sitzung zu starten hiesse, Sekunden zu warten, um fünf Sekunden zurückzugehen. **Und die Sitzung wird geschlossen.** `endPlayback` war eine leere Methode; das passte, solange es keine Sitzung gab. Mit dem Strom läuft sonst ein ffmpeg weiter und schreibt den Film zu Ende, während längst niemand mehr zusieht. Die Laufzeit kommt weiter aus den Metadaten und nicht aus der Engine: eine wachsende Liste meldet anfangs ein paar Sekunden, und als Filmlänge genommen stünde der Regler sofort am Ende. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 14:22:18 +02:00
ScarriffleandClaude Opus 5	c5ab200846	Die Startseite holte ihre Reihen im Gänsemarsch ... Die Weboberfläche holt alles, was auf der Startseite steht, in einem einzigen `Promise.all` — und sie holt sogar mehr davon: Vorschlag und saisonale Reihe kennt die App gar nicht. Trotzdem war sie spürbar langsamer. Der Grund stand in einer Schleife: for mediathek in mediatheken { ... await client.send(...) } Ein `await` im Schleifenrumpf heisst: Rundreise, warten, nächste Rundreise. Bei vier Mediatheken viermal hintereinander, nachdem „Fortsetzen" und „Als Nächstes" längst da waren. Dieselbe Schleife stand in beiden Hintergründen, für Flaro wie für Jellyfin. Jetzt laufen sie nebeneinander, in einer `TaskGroup`. Die Reihenfolge der Mediatheken bleibt erhalten — nach den Antworten zu ordnen hiesse, dass die Reihen nach jedem Start woanders stünden. Ein Actor steht dem nicht im Weg: jede Anfrage gibt ihn beim Warten frei, genau wie die beiden `async let` darüber es schon tun. Nebenbei: ein Fehler bei einer Mediathek nimmt die anderen nicht mehr mit. Eine Startseite mit drei von vier Reihen ist besser als keine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-10 13:55:24 +02:00
ScarriffleandClaude Opus 5	e30158b84c	Eine Sekunde heisst nicht „Weiterschauen" ... Die Schwelle aus den Einstellungen wirkt serverseitig, also sofort überall: `/home/continue` liest die gespeicherte Spalte. Eine Stelle blieb trotzdem widersprüchlich — die **Beschriftung**. Web und Apps entschieden „Weiterschauen" gegen „Abspielen" selbst, allein daran, ob eine Stelle über null steht. Nach einer Sekunde stand der Titel damit nicht mehr in der Reihe, hiess aber weiter „Weiterschauen", trug einen Fortschrittsbalken unter der Kachel und bot „Aus Weiterschauen entfernen" an. Der Server hatte diese Frage längst beantwortet. `ItemStateResponse` bringt sie jetzt mit; `MediaItem.isResumable` und `.resumeProgress` sind die einzigen Stellen, die sie noch stellen. Im Simulator nachgeprüft: nach einer Sekunde heisst der Knopf „Abspielen", „Von vorn" fehlt, und der Balken unter der Kachel ist weg. Kennt ein Server das Feld nicht — Jellyfin, oder ein älterer Flaro —, gilt wie früher die blosse Stelle. **Und das Profilbild steht in den Apps.** `FlaroAccount` führt es mit, `/auth/me` bringt es bei jedem Start frisch, und der Buchstabenkreis tritt zurück, sobald eines da ist. Jellyfin bleibt beim Buchstaben — dort gibt es kein Profilbild, und das ist keine Lücke, sondern der Stand der Dinge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-06 17:30:38 +02:00
ScarriffleandClaude Opus 5	10a5070e58	Eine Folge ist weder ein Film noch eine Serie ... Die App meldete auf der Startseite „Dieser Titel ist auf dem Server nicht mehr vorhanden" — über eine Folge, die sie selbst gerade anzeigte. Gemessen im Quelltext: `item(id:)` probiert `/movies/{id}`, dann `/series/{id}`, und wirft sonst `.notFound`. In „Weiterschauen" steht eine Folge mit ihrer eigenen Kennung, und einen Endpunkt für eine einzelne Folge gab es gar nicht. Jetzt gibt es `GET /api/v1/episodes/{id}` — mit `SeriesId`, denn ohne die Serie fehlen der Folge Titel und Bild. Im Simulator nachgestellt und nachgeprüft: die Seite steht. **Zuletzt hinzugefügt.** Die App zeigte „Filme" und „Serien" — den Anfang der Mediathek in der Reihenfolge der Datenbank, also immer denselben. Jetzt je Mediathek eine Reihe „Neu in …", sortiert nach Zugang. Die Kennungen beginnen nun mit `latest`, und daran hängen zwei Einstellungen, die an einem Flaro-Server deshalb nichts taten: „Gesehenes in Neuzugängen ausblenden" und „Aufmacher nur aus Neuzugängen". **Geplante Titel.** `MediaItem` kennt jetzt `availableFrom`. Aufmacher und Detailseite zeigen statt des Knopfes „Bald ist es soweit" mit dem Termin. Die Kachel spielte trotzdem los — im Simulator kam der Spieler bis „Wird vorbereitet …" —, also zählt ein geplanter Titel jetzt wie eine Sammlung: nichts zu starten, der Tipp führt auf die Seite. **Und das Bild im Aufmacher.** Bei einer angefangenen Folge stand dort ihr Standbild statt des Bildes der Serie; wer der Serie eines ausgesucht hatte, fand ein anderes vor. Die Kachel behält das Standbild — sie zeigt, wo man steht —, der Aufmacher bekommt `SeriesBackdropImage`. **Die Punkte im Karussell waren 26 × 3 Pixel.** Von drei Klicks auf denselben Punkt traf nur der auf der Mittellinie; fünf Pixel daneben geschah nichts. Der Knopf ist jetzt 27 Pixel hoch, sichtbar bleiben 3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-06 16:06:58 +02:00
ScarriffleandClaude Opus 5	172b38da06	Die Apps können jetzt beides: Jellyfin oder Flaro ... `FlaroServerKit` steht neben `JellyfinKit`, nicht darin — genau auf dem Steckplatz, den Plex geräumt hat. Dass `MediaBackend` zwei Server zugleich trägt, war schon einmal bewiesen; die Naht hat gehalten, und keine einzige Ansicht musste dafür neu geschrieben werden. `ServerKind` ist zurück. Es wurde beim Entfernen von Plex gestrichen, weil ein Aufzählungstyp mit einem Fall ein umständliches Bool ist. Jetzt gibt es wieder zwei, und es ist wieder eine Unterscheidung — einer zur Zeit, nicht beide nebeneinander. **Flaro steht oben auf dem Anmeldebildschirm.** Nicht aus Eitelkeit: dort bringt ein Download alle Tonspuren mit und der Fortschritt wird ab der ersten Sekunde gemerkt. Wer Jellyfin benutzt, sucht gezielt danach — wer neu anfängt, soll nicht in der schwächeren Hälfte landen, weil ihr Knopf auffälliger war. Am Fernseher steht bei beiden der sechsstellige Code voran. --- **Der Zugang geht als Cookie, nicht in der Adresse.** Jellyfin hängt sein Token an jede Bildadresse, weil eine Bildansicht keine Kopfzeilen schickt; es steht damit in jedem Zugriffsprotokoll und jedem weitergegebenen Link. Flaro tut das nicht, und deshalb legt der Client sein Token selbst im gemeinsamen Keksspeicher ab — auch beim Wiederaufnehmen aus dem Schlüsselbund, wo gar keine Anmeldung stattfindet und der Server es nie setzen könnte. `URLSession` schickt es von allein mit; **AVFoundation nicht**. Der Systemplayer bekommt die Kekse jetzt ausdrücklich. Serverneutral: wo keine liegen, ist die Liste leer. **`BackendCapability.allTracksDownload`** statt einer Spurwahl, die ins Leere führt. Die Frage „welche Tonspur?" gibt es nur, weil Jellyfins Transcoder eine je Sitzung abbildet. Bei Flaro führen beide Antworten zum selben Ergebnis — also wird nicht gefragt, und das Umpacken mit einer einzigen Spur entfällt gleich mit. **Die Adressraterei wandert nach `MediaKit`.** Sechzig Zeilen sorgfältig begründeter Reihenfolge — IP-Adressen sprechen selten HTTPS, Domänennamen fast immer — unterscheiden sich zwischen beiden Servern nur im Standardport. Zweimal hingeschrieben wäre die eine Fassung beim nächsten Sonderfall nachgezogen worden und die andere nicht. Jellyfins Prüfungen laufen unverändert gegen die verschobene Fassung; das ist der Beweis. **Nebenbei zwei Altlasten:** `player.jellyfinPending` war unerreichbar — der Player zeigt diese Meldung nur, wenn gar kein Server da ist, dann aber nie die mit Jellyfin. Und `signIn.jellyfin.userName` hiess „Benutzername"; der Schlüssel heisst jetzt so neutral wie der Text. --- **Der Fehler, den erst der Simulator zeigte:** „Stelle wird wiederhergestellt", 0:00, für immer. Muss der Server umpacken, antwortet er auf den Download mit 202 und fängt an. AVPlayer bekommt darauf kein Video, sondern eine leere Antwort — und wartet, unbegrenzt, ohne Fehler. Die Weboberfläche fragt in einer Schleife nach; `preparePlayback` tat es nicht. Jetzt wartet es, mit Obergrenze und einer Begründung, wenn sie reisst. Mit Prüfung, die zwei Runden erzwingt. 413 Tests grün. Im Simulator gegen den echten Server nachgewiesen: Adresse eintippen, Server gefunden, angemeldet, Mediathek mit Plakaten, Neustart ohne erneute Anmeldung — und eine MKV abgespielt, die der Server dafür erst umpacken musste. Danach stand auf dem Server: Matrix, 2,0 s von 2,0 s, gesehen, ein Durchlauf. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 22:00:02 +02:00
ScarriffleandClaude Opus 5	a7cf6c5def	Halo heisst ab hier Flaro — die Marke stand im Weg ... Der Upload zu App Store Connect scheiterte am Namen. „Halo" ist eine eingetragene Marke von Microsoft; im App Store heisst zwar keine App exakt so, aber reservierte und markenrechtlich belegte Namen tauchen in keiner Suche auf. Der einzige verlässliche Test war die Eingabe dort, und die ging daneben. **Der Name wurde diesmal vorher geprüft.** Zwanzig Kandidaten gegen den deutschen und amerikanischen App Store, auf exakte Treffer und auf ähnliche Namen. „Kavo" wäre dieselbe Wand gewesen — exakt belegt in beiden Stores, in Deutschland von KaVo Dental GmbH. „Flare" ist mit 42 ähnlichen Apps je Store der am dichtesten besetzte Name der ganzen Runde. **Flaro** ist in beiden frei und liest sich als eigenes Wort, nicht als Flare mit Tippfehler. Das bleibt eine Store-Suche und keine Markenrecherche — reservierte Namen ohne veröffentlichte App sieht sie nicht. Aber es ist mehr Prüfung, als beim letzten Mal stattfand. --- 2160 Textvorkommen in 273 Dateien, 49 Pfade. Betroffen ist diesmal auch der Server: `Flaro.Api`, `Flaro.Core`, `Flaro.Data`, `Flaro.Media`, `Flaro.Metadata`, `FlaroContext`, `FlaroPaths`, `flaro.db`, die Variablen `FLARO_DATA`, `FLARO_CACHE`, `FLARO_TRANSCODE`, `FLARO_WRITE_SIDECARS`, und das Image. **Vor dem Ersetzen geprüft**, ob „halo" irgendwo als Teil eines anderen Wortes steckt — und ob es im TMDB-Token vorkommt. Tat es nicht; ein blindes Ersetzen hätte den sonst zerlegt. `docs/superpowers/specs/` bleibt wie beim letzten Mal unangetastet: datierte Entwurfsdokumente sind ein Protokoll getroffener Entscheidungen. Das Server-Dokument hat stattdessen einen Nachtrag bekommen, damit es niemanden in die Irre führt. **Die Bundle-ID wandert mit**, zum zweiten Mal an einem Tag: `com.scarriffleservices.flaro`. Wer die vorige Fassung installiert hat, hat jetzt zwei Karteileichen auf dem Gerät — beide löschen, dann ist Ruhe. 308 Server-Tests grün, 368 im Swift-Paket, null Warnungen. iOS und tvOS bauen, das Image baut, und ein frischer Container läuft durch Einrichtung und Anmeldung. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 19:38:27 +02:00
ScarriffleandClaude Opus 5	4b9a1e7b67	Flixy heißt ab hier Halo ... Reine Umbenennung, kein Verhalten geändert — bewusst als eigener Commit, damit „umbenannt" und „umgebaut" im Nachhinein auseinanderzuhalten sind. 712 mal `Flixy`, 778 mal `flixy`, 7 mal `FLIXY` in 169 Dateien, dazu 25 Pfade. Ziele: `Halo`, `HaloTV`, `HaloTopShelf`, `HaloUITests`, `HaloKit` mit `HaloDesign`, `HaloDownloads`, `HaloPlayback` und `HaloProbe`. `MediaKit`, `JellyfinKit` und `DownloadWidget` tragen den Namen nicht und bleiben. `docs/superpowers/specs/` ist ausgenommen. Datierte Entwurfsdokumente sind ein Protokoll getroffener Entscheidungen; sie nachträglich umzuschreiben hiesse, die Vergangenheit zu glätten. **Die Bundle-ID wandert mit** — ausdrücklich so gewollt, mit bekanntem Preis: `com.scarriffleservices.halo` ist für iOS eine *andere* App. Die installierte Fassung bleibt daneben stehen, mit Downloads und Anmeldung in ihrem Container; Halo startet leer. Einmal neu anmelden, heruntergeladene Folgen einmal neu laden. Dasselbe gilt für die App-Gruppe, die sich TV-App und Top Shelf teilen. **Eine Folge davon, die beim Entscheiden noch nicht auf dem Tisch lag:** der Aufräumschritt aus dem vorigen Commit kommt an die alten Plex-Token nicht mehr heran. Der Schlüsselbund grenzt nach Team und Bundle-Kennung ab — was unter `…flixy` liegt, ist für `…halo` unerreichbar. Erledigt wird es trotzdem, nur anders: **die alte App löschen.** iOS räumt deren Schlüsselbund-Einträge beim Deinstallieren mit ab. Der Code bleibt stehen, weil er für jeden Stand vor dieser Umbenennung richtig ist und im Jahr einen Startvergleich kostet. Die Projektdatei ist aus `project.yml` neu erzeugt, der alte Ordner gelöscht statt umbenannt — sie steht ohnehin nicht im Repo. Das Verzeichnis des Repos selbst heißt weiter `Flixy`; das umzubenennen ist ein Handgriff ausserhalb des Projekts. 368 Tests grün. iOS und tvOS bauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 11:12:32 +02:00
ScarriffleandClaude Opus 5	2fcf6821c8	Plex ist raus — und nahm zwei stille Fehler mit ... Vollständig entfernt: das Paket `PlexKit` samt 108 Tests, der Web-Authenticator, die Anmeldung über plex.tv, die Serverauswahl und alles, was daran hing. 43 Dateien gelöscht, 68 Stellen in 28 weiteren bereinigt. **Zwei Dinge hätten beim blossen Streichen still das Falsche getan.** `playbackUnavailableMessage` deckte im Else-Zweig zwei Lagen gleichzeitig ab — „es ist Plex" und „niemand ist angemeldet". Wer die Serverart naiv herausstreicht, bekommt als nicht angemeldeter Nutzer „Jellyfin-Wiedergabe steht aus" statt „Server nicht erreichbar". Die Unterscheidung hängt jetzt daran, ob überhaupt ein Server da ist. Die Schlüsselbund-Einträge `plex.account` und `plex.server` wurden allein über den Authenticator aus dem gelöschten Paket entfernt. Danach stünde `plex.account` in keiner Zeile dieses Projekts mehr: wer sich nie abgemeldet hat, trüge ein gültiges Token am fremden Konto bis in alle Ewigkeit mit sich, ohne dass irgendein Weg es noch löschen könnte. `purgePlexLeftovers()` räumt beide Token und fünf Voreinstellungen einmalig ab — und fasst nichts an, wo nichts liegt, damit kein Jellyfin-Nutzer dafür seinen Mediathekenspeicher verliert. **Was Nutzer sehen.** Die Berechtigungsfrage fürs lokale Netz sagte wörtlich, die App brauche es, „um deinen Plex-Server zu finden" — das stand so im Systemdialog. Der Anmeldebildschirm hatte zwei Knöpfe, und der hervorgehobene war der für Plex; der verbliebene erbt die Hervorhebung, denn ein Knopf, der aussieht wie die zweite Wahl, lässt nach der ersten suchen. 14 verwaiste Textbausteine sind weg, vier umformuliert. Darunter einer, der schlicht nicht mehr stimmte: `signIn.privacy` versprach, das Passwort erreiche diese App nie. Beim Jellyfin-Rückfall auf das Passwort tut es das sehr wohl. Die Zusage, die weiterhin gilt, ist die über fremde Dienste — und nur die steht jetzt da. **Was ausdrücklich bleibt:** `MediaBackend`. Diese Abstraktion hat zwei Server gleichzeitig getragen, und der Steckplatz, den Plex räumt, ist genau der, auf den Halo kommt. `ServerKind` fällt dagegen weg — mit einem Fall ist es ein Bool, das `backend != nil` schon beantwortet. Nebenbei zog die README nach. Sie beschrieb noch einen „nativen Plex-Client" mit zwei Playern und VLCKit, beides seit Längerem nicht mehr wahr. 368 Tests grün (von 476 minus die 108 aus PlexKitTests, kein anderer). iOS und tvOS bauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 11:10:20 +02:00
ScarriffleandClaude Opus 5	6b6bc6ad02	Der Server lieferte nichts — drei Angaben fehlten in der Adresse ... Am echten Server gemessen, nachdem der erste Versuch mit „Fehler 500" abgelehnt wurde. Drei Befunde, alle reproduziert: **`deviceId` und `playSessionId` fehlten.** Ohne sie antwortet Jellyfin mit `200` und `Content-Length: 0` — kein Fehler, keine Datei, nichts. Mit ihnen kamen in fünfzehn Sekunden 66 MB. Das betraf **auch die verkleinerten Fassungen**: `compressedDownloadURL` hatte sie nie. „In 480p herunterladen" war damit die ganze Zeit folgenlos — ein Fehler, der älter ist als alles von heute. **Die Sitzungskennung muss je Auftrag neu sein.** Zuerst hatte ich sie an die Titelkennung gehängt, damit ein Wiederholversuch dieselbe Sitzung bleibt. Zwei Anfragen unter derselben Kennung hielt der Server aber für dieselbe Sitzung und antwortete der zweiten mit einer leeren Datei. Jetzt eine UUID beim Anlegen des Auftrags — eindeutig je Download, gleich über alle Wiederholversuche, weil die Adresse gespeichert ist. **`subtitleCodec=mov_text` muss dabeistehen.** Das war der Fehler 500. Mit `subtitleMethod=Embed` allein lehnt der Server ab; derselbe Aufruf ohne Untertitel liefert 61 MB, mit Untertitel und `mov_text` 42 MB samt Spur. MP4 kennt kein SubRip — wer den Untertitel hineinlegen will, muss sagen, als was. Nachgewiesen im Simulator gegen den echten Server: „100,0 MB / 917,3 MB · 6,1 MB/s · noch 2 Min · 11 %". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 08:46:02 +02:00
ScarriffleandClaude Opus 5	a432592271	Beim Umpacken fällt die Spurwahl an — also wird sie dort getroffen ... Dein Befund an „Notruf Hafenkante": keine Spuren, nichts auswählbar. Die technischen Angaben derselben Folge sagen, warum: Container MKV Tonspur AAC - Stereo - Standard Tonspur Deutsch - German - AAC - Stereo - Standard Untertitel German - Standard - SUBRIP Die Quelle ist Matroska. AVFoundation öffnet das nicht, also lief der Download bisher über die zweite Engine — und die meldete die Spurliste leer. Offline wählen ging damit nie. **Umpacken allein hätte es nicht gelöst.** Jellyfin bildet in die neue Hülle genau **eine** Tonspur ab und übernimmt den Untertitel nur, wenn man ihn nennt. Ohne Angabe nimmt der Server seine eigene Vorgabe — und das ist bei deutschen Aufnahmen regelmäßig die Spur mit Audiodeskription. Also fällt die Wahl jetzt beim Herunterladen, mit derselben Abwägung wie beim Abspielen (`AudioTrackChooser`, der für genau diesen Fall gebaut wurde: die als deutsch ausgezeichnete Spur ist die mit Audiodeskription). Der Untertitel geht als `subtitleMethod=Embed` mit — als **Spur**, nicht ins Bild gebrannt, sonst liesse er sich nicht abschalten. Die Mediathek bleibt bei der Abwägung aussen vor: sie nachzuschlagen kostet eine Anfrage je Folge, und Serie und allgemeine Einstellung tragen den Wunsch ohnehin. Der Offline-Abzug behauptet nicht mehr, alle Sprachen seien dabei — beim Umpacken bleibt je eine übrig, und alle zu notieren wäre ein Versprechen, das die Datei nicht hält. **Nebenbei richtiggestellt:** die technischen Angaben rechneten mit `.directPlayOnly` und zeigten deshalb „Direkt (Systemplayer)" direkt über „iOS öffnet den Container MKV nicht" — zwei Angaben, die sich widersprechen. Das war früher richtig (ohne Serverhilfe übernahm die zweite Engine und hiess auch so); jetzt wird mit Serverhilfe gerechnet. NOCH NICHT AN EINEM ECHTEN SERVER GEPRÜFT. iOS und tvOS bauen, 494 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 08:32:41 +02:00
ScarriffleandClaude Opus 5	6b927c21b0	VLC ist weg — es gibt nur noch einen Spieler ... Du hattest recht mit der Erwartung, nur nicht mit dem Stand: entfernt war er nicht. Was wir gemacht haben, war, ihm Arbeit wegzunehmen — DTS, TrueHD und Vorbis gehen seit Kurzem über das Umpacken beim Server. Übrig blieb er an einer Stelle, `PlaybackDecider.fallback`. Jetzt ist er ganz weg, samt dem 920-MB-Binärpaket. **Was an seine Stelle tritt.** Die Entscheidung sagt nicht mehr, *wer* spielt, sondern *was ankommt*: direkt, umgepackt oder umgerechnet. `PlaybackEngineKind` fällt damit weg, `directPlay` trägt keine Engine mehr, und `PlaybackPolicy` kennt kein `allowsFallbackEngine`. **Das Auffangnetz bleibt, nur anders geknüpft.** Scheiterte das Umpacken am Player, sprang bisher VLC ein — der Server entscheidet erst beim Ausliefern, ob er die Ströme wirklich kopieren kann, und manche Antworten nimmt AVPlayer nicht an. Statt der zweiten Engine rechnet der Server jetzt neu (`fallBackToTranscode`). Teurer für ihn, aber es kommt etwas an, statt einer schwarzen Wand mit einer Fehlernummer. **Offline wäre das ein Rückschritt gewesen** — dort gibt es keinen Server, der einspringt. Deshalb ging der vorige Commit voraus: was heruntergeladen wird, kommt schon in einer Hülle, die der Systemplayer öffnet. Was dadurch überall gilt, auch für Dateien, die bisher bei VLC landeten: Bild-in-Bild, AirPlay, Bedienung im Sperrbildschirm — und dasselbe Verhalten auf dem Apple TV, wo es VLC ohnehin nie gab. Die Attrappe heißt ihren Schalter jetzt `--dts` statt `--vlc`: der Fall ist geblieben, sein Ziel nicht. iOS und tvOS bauen, 494 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 08:04:23 +02:00
ScarriffleandClaude Opus 5	ef2596e2bb	Was heruntergeladen wird, muss der Systemplayer öffnen können ... **Vorbereitung dafür, dass VLC verschwindet.** Online ist der Fall längst gelöst: steht nur die Schachtel im Weg, packt der Server um — dieselben Ströme, eine MP4-Hülle. Offline gibt es diesen Ausweg nicht. Was einmal als Matroska auf dem Gerät liegt, kann hinterher niemand mehr umpacken, und ohne zweite Engine bliebe die Datei schwarz. Also entscheidet sich das beim Herunterladen. Fragt jemand das Original an und AVFoundation könnte die Datei nicht öffnen, wird `remuxDownloadURL` benutzt: `/Videos/{id}/stream.mp4` mit `allowVideoStreamCopy` und `allowAudioStreamCopy`. Der Server reicht durch, was passt, und rechnet nur um, was nicht passt — das Bild bleibt das Original, nur DTS oder TrueHD werden zu AC3 oder AAC. Drei Dinge hängen daran und sind mitgezogen: - Die **Größe** ist dann keine Zusage mehr: dieselben Ströme in einer anderen Hülle wiegen anders. `expectedIsExact` fällt auf falsch, und es gilt wieder die weiche Prüfung. - Der **Container** im Offline-Abzug ist „mp4", nicht die alte Schachtel. Sonst entschiede der Player anhand einer Datei, die es so nicht mehr gibt. - Der **Tonkodierer** bleibt leer. Ob aus DTS dann AAC oder AC3 wird, sagt der Server vorher nicht; eine Behauptung wäre schlechter als die Lücke, und die Spuren liest der Player ohnehin aus der Datei. **Die Frage „kann das der Systemplayer?" steht jetzt an einer Stelle.** `DeviceCapabilities.opens(container:videoCodec:audioCodec:)` — dieselbe Liste, nach der auch beim Abspielen entschieden wird. Was der Server nicht nennt, gilt als passend: vorsichtshalber umzupacken hiesse, aus einer tadellosen MP4 eine neu gerechnete Datei zu machen. Fünf Tests. NOCH NICHT AN EINEM ECHTEN SERVER GEPRÜFT: ob Jellyfin das Kopieren hier tatsächlich wählt, verrät erst die Dateigröße des ersten Downloads. 140 Tests in FlixyPlayback, iOS und tvOS bauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-03 07:54:46 +02:00
ScarriffleandClaude Opus 5	e86c0a6e95	Ein Download riss ab, galt als fertig — und setzte nie fort ... Dein Bericht: bei rund 3 GB abgebrochen, beim Fortsetzen wieder bei null, und später „plötzlich bei 60 Prozent fertig". Beide Hälften standen so im Code. **Fertig war sie nicht, sie war halb.** if expected > 0, Double(written) < Double(expected) * 0.5 { verwerfen } Alles über der Hälfte galt als vollständig. Diese Regel war nie für diesen Fall gedacht, sondern für die **hochgerechnete** Größe der Transcoder-Stufen (Bitrate × Dauer) — dort ist Abweichung normal. Beim Original nennt der Server die Dateigröße in den Metadaten, und da ist jedes fehlende Byte ein Abriss. Das unterscheidet jetzt `expectedIsExact`, gesetzt beim Planen und mitgeführt am Eintrag. Dazu merkt sich der Koordinator, für welche Titel der Server eine `Content-Length` geschickt hat — auch das ist eine Zusage. **„Fortsetzen" war eine Zusage, die der Code nicht halten konnte.** `NSURLSessionDownloadTaskResumeData` kam im ganzen Projekt nicht vor; den Wiederaufnahme-Datensatz gab es nur beim Pausieren von Hand. Nach einem Netzfehler war er weg, und der Knopf daneben hieß trotzdem „Fortsetzen". Jetzt wird er aus dem Fehler gerettet, und wo es ihn nicht gibt, heißt der Knopf „Erneut versuchen". **Und es merkte niemand, wenn das WLAN zurückkam.** `RootView` reicht das jetzt weiter — nur für Einträge mit Wiederaufnahme-Datensatz, damit ein 404 sich nicht im Kreis versucht. **Rate und Restzeit** stehen in der Zeile: „12 MB / 20 MB · 3,4 MB/s · gleich fertig". `DownloadRate` ist ein reiner Wertetyp mit Uhr von außen — geglättet, weil rohe Differenzen um ein Vielfaches springen, und ohne Zahl, solange nichts gemessen ist. Neun Tests. **Zwei Dinge, die erst die Messung gezeigt hat** — und die beide nicht in der App liegen: Erstens: reißt eine Übertragung ab, **die eine `Content-Length` angekündigt hatte**, wiederholt die Hintergrundsitzung von iOS sie selbst — stumm, ohne den Delegaten zu fragen, und **jedes Mal ab Byte null**. Gemessen: sieben Anläufe, jeder die vollen 12 MB. Das ist genau dein „fing wieder bei null an", und dagegen hilft kein Wiederaufnahme-Datensatz. Zweitens: ein Fortsetzen braucht eine Prüfmarke vom Server. Ohne `ETag` oder `Last-Modified` kann iOS sein `If-Range` nicht stellen und lädt alles noch einmal — gemessen, 20 MB zweimal. Mit Marke kam die zweite Anfrage als `Range: bytes=5636096-` und holte nur den Rest. Die Attrappe kann das jetzt alles nachstellen: eine beliebig große Datei, die auf Wunsch mittendrin abreißt, mit oder ohne angekündigte Länge, und gedrosselt. Ohne sie ist nichts davon beweisbar — und genau daran ist der Fehler vorbeigekommen. Im Simulator gegen die Attrappe: 12 von 20 MB → „Fehlgeschlagen: Übertragung unvollständig", nicht Haken. Vollständig → Haken. iOS und tvOS bauen, 489 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-02 21:05:34 +02:00
ScarriffleandClaude Opus 5	c37087fd34	Auf dem Telefon stand ein Plakat im Aufmacher — zweimal derselbe Name ... Der Aufmacher auf dem iPhone hat nicht das Hintergrundbild geholt, sondern das **Plakat**. Dafür gab es einen Grund, und er stimmte: ein 16:9-Bild in einem 2:3-Rahmen ist ein Streifen aus der Mitte. Nur war der Rahmen das Problem, nicht das Bild. Ein Plakat trägt den Titel selbst, und darüber legt der Aufmacher noch den freigestellten Schriftzug — derselbe Name zweimal, einmal gesetzt und einmal gemalt. **Jetzt ein Querbild in einem 4:3-Rahmen.** 16:9 ginge nicht: das sind auf 440 Punkten Breite 248 Punkte Höhe, und darin sollen Schriftzug, Zeile, ein Satz Beschreibung und zwei Knöpfe stehen. Sie standen schon einmal übereinander, das ist der dokumentierte Grund für das Hochformat. 4:3 gibt 330 Punkte — gemessen passt der Text hinein; dafür fehlt dem Bild links und rechts zusammen ein Viertel. **Die Detailseite bleibt hochkant.** Dort hat man sich schon entschieden; das Plakat ist das Bild dieses Films, und du wolltest den Kopf der Seite ausdrücklich höher. Beide Seiten lasen bisher aus **derselben** Funktion — eine Änderung für den Aufmacher hätte die Detailseite von 660 auf 330 Punkte gestutzt, ohne dass irgendwo ein Fehler aufgetaucht wäre. `HeroArtwork` kennt deshalb jetzt den Verwendungszweck: HeroArtwork.aspectRatio(.detailHeader, compact: …) // 2:3 HeroArtwork.aspectRatio(compact: …) // 4:3 bzw. 16:9 Maße, Verhältnis und Reihenfolge der Bildpfade hängen alle an **einer** privaten Abfrage — sie müssen zusammenpassen, sonst beschneidet der Server anders als der Rahmen. Die Maße schmal: 1200×900 statt 1920×1080. Der Rahmen ist dort höchstens 1320 Bildpunkte breit; das spart auf einer Mobilfunkverbindung ein Drittel. Gemessen im Simulator (iPhone 17 Pro Max): Aufmacher 4:3, Text passt, Detailseite unverändert hochkant. iOS und tvOS bauen, 476 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 12:57:42 +02:00
ScarriffleandClaude Opus 5	2ab05ee8f6	Der Schriftzug gehörte zum vorigen Film — ein Zustand ohne Adresse ... „Werner Beinhart" über dem Bild von John Wick. Von mir eingebaut, im Commit, der die Überblendung umgestellt hat. **Der Grund ist der Umbau selbst.** Vorher bekam der Aufmacher je Titel eine neue Identität; sein Zustand begann damit jedes Mal von vorn. Seit er bleibt und nur seine Angaben wechseln, überlebt auch der geladene Schriftzug den Wechsel — und `availableLogo` gab ihn heraus, ohne zu prüfen, ob er überhaupt zum aktuellen Titel gehört: if let logo { return logo } // ← zu irgendeinem Film Jetzt trägt der Zustand die Adresse mit, zu der er gehört, und wird nur herausgegeben, wenn sie zur aktuellen passt. Passt sie nicht, gilt der Zwischenspeicher — und wenn auch der nichts hat, der gesetzte Titel. Nie der falsche Schriftzug. **Dieselbe Falle steckte in `FlixyArtwork`**, nur unauffälliger: auch dort hielt `loaded` ein Bild ohne Angabe, wozu es gehört, und `load()` brach deswegen früh ab („ist ja schon eins da"). Solange jede Kachel ihre eigene Identität hat, fällt das nicht auf. Der Aufmacher hat seit dem Umbau keine mehr. Die Regel dahinter gilt allgemein: **ein Zustand, der etwas zwischenspeichert, muss sagen, wozu es gehört** — sonst gilt er für alles. Die Attrappe liefert jetzt Schriftzüge (`Logo`-Bildmarke). Ohne sie fällt der Aufmacher auf den gesetzten Titel zurück, und dieser ganze Weg wäre im Simulator gar nicht zu sehen — genau deshalb ist der Fehler erst beim Nutzer aufgefallen. iOS und tvOS bauen, 476 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 12:29:26 +02:00
ScarriffleandClaude Opus 5	37bb153dd8	Der Schriftzug wandert wieder mit — über dem Verlauf statt in ihm ... Im Commit davor blendete nur noch das Bild über; Schriftzug, Zeile und Knöpfe standen still und wechselten schlagartig. Das war zu viel weggenommen: die Bewegung gehört dazu. Jetzt wandert der Text wieder mit — aber an der richtigen Stelle im Stapel. Der Aufmacher zeichnet seinen Inhalt während eines Wechsels zweimal: den weichenden deckend, den kommenden mit demselben Einblenden und demselben Hereinrutschen wie das Bild darunter. Beides liegt **über** dem Verlauf, und dort kostet es ihn nichts. Der Unterschied zum alten Aufbau ist genau diese Reihenfolge. Vorher lagen zwei **vollständige** Aufmacher übereinander, jeder mit eigenem Verlauf — und zwei halbdurchsichtige Verläufe ergeben zusammen keinen ganzen. Jetzt gibt es einen Verlauf, einmal, in voller Stärke. Nachgemessen über einen auf sechs Sekunden gestreckten Wechsel, an derselben Stelle im Bild: ursprünglich 68 .. 154 jetzt 63 .. 75 Dafür ist der Textsatz in `HeroBanner` eine eigene Funktion geworden — es gibt ihn während eines Wechsels zweimal — und `HeroSection.metadata` ist `static`, weil die Zeile auch für den weichenden Titel gebraucht wird. `titleView` und `plainTitle` sind darin aufgegangen. iOS und tvOS bauen, 476 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 12:18:58 +02:00
ScarriffleandClaude Opus 5	63c664e5a9	Der Aufmacher hellte beim Wechsel auf — zwei Verläufe ergeben keinen ... Beim Wechsel im Karussell war der Verlauf nach unten für einen Moment weg: das Bild stand bis unten hell da, und erst nach dem Übergang kam das Abdunkeln zurück. **Der Grund steckt in der Form der Überblendung.** Das Karussell legte zwei vollständige Aufmacher übereinander und blendete den oberen ein. Nur bringt jeder von beiden seinen eigenen Verlauf mit — und zwei halbdurchsichtige Verläufe ergeben zusammen keinen ganzen. Gemessen, an derselben Stelle im Bild, über einen auf sechs Sekunden gestreckten Wechsel: Ruhezustand 68 .. 75 Mitte des Wechsels 137 ← fast doppelt so hell Zwei naheliegende Reparaturen habe ich davor versucht und verworfen, weil die Messung sie widerlegt hat: dem weichenden Aufmacher die Animation zu nehmen (wurde schlechter, 152) und beide Ebenen gegenläufig zu blenden (brachte einen dunklen Einbruch auf 35 dazu). Beide behandelten das Symptom, nicht die Form. **Jetzt wechselt nur das Bild.** `HeroBanner` nimmt zusätzlich die weichende Bildadresse entgegen und blendet **innen** über; Verlauf, Schriftzug und Knöpfe liegen einmal darüber und ändern sich dabei nicht. Damit kann der Verlauf gar nicht mehr schwächer werden — nicht weil es jetzt richtig gerechnet wird, sondern weil es nur noch einen gibt. Nachgemessen, derselbe Wechsel: vorher 68 .. 154 jetzt 63 .. 75 Die Aufmacher-Ansicht behält dabei ihre Identität, statt je Titel eine neue zu bekommen: eine neue hiesse Einfügen und Entfernen, und SwiftUI blendete sie dann zusätzlich ein — noch eine Überblendung über der gemeinten. iOS und tvOS bauen, 476 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 11:11:22 +02:00
ScarriffleandClaude Opus 5	a665d79e6d	Antippen spielt ab — und vier Dinge, die daneben lagen ... **Antippen startet, langes Drücken führt auf die Detailseite.** Am Telefon und am iPad; am Mac bleibt der Klick die Seite, denn dort gibt es den Abspielknopf beim Überfahren und langes Drücken ist keine übliche Geste. Die Hürde war nicht die Geste, sondern das Schieben: ein `NavigationLink` schiebt selbst, ein Menüeintrag kann es nicht. Der Stapel ist deshalb ein eigener Typ mit Pfad (`MediaStack`) und reicht eine Schiebefunktion über die Umgebung nach innen — denselben Weg nimmt schon die Meldung, dass sich am Server etwas geändert hat. **Zwei Knöpfe übereinander auf der Detailseite.** Das Monogramm hing als Überzug an `mediaStack` — also über **jedem** Bildschirm dieses Stapels, auch den geschobenen, und dort über deren Drei-Punkte-Menü. Es gilt jetzt für die Startseite und endet mit ihr. **Der Kopf der Detailseite war viel zu flach.** Dort stand kein Seitenverhältnis, also galt die Vorgabe 16∶9 — während `HeroArtwork` auf einem schmalen Gerät ein **Plakat** anfordert, also hochkant. Zu sehen war ein Streifen aus der Mitte. Der Aufmacher auf der Startseite macht es seit Langem richtig; die beiden Detailseiten nicht. **Die Mediathekenleiste stand linksbündig in einer halbleeren Kapsel.** Jetzt ist sie so breit wie ihr Inhalt und mittig. `ViewThatFits` nimmt die ungescrollte Reihe, solange sie passt, sonst die scrollbare — damit steht nirgends eine Zahl, ab wann es kippt. **Und der Grund, warum die Mediathekenauswahl beim Nutzer nie griff:** Plex. Dessen Hubs sagten nicht, aus welcher Mediathek sie stammen, also warf der Filter jede Reihe weg und fiel auf „alles" zurück — ein Schalter, der nichts tut. `PlexHub` liest jetzt `librarySectionID`, als Zahl oder als Zeichenkette, je nachdem was der Server liefert. Vier Tests dazu. Das ist **kein** Wiederaufnehmen der Plex-Arbeit: es repariert eine Funktion, die dort gelogen hat. Neues kommt weiterhin nicht dazu. iOS und tvOS bauen, 476 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 10:39:45 +02:00
ScarriffleandClaude Opus 5	1fa8011094	Eine Mediathek fehlte ganz — „Heimvideos" lagen bei den Fotos ... Jellyfin nennt „Heimvideos & Fotos" `collectionType: homevideos`. Die Zuordnung legte das zusammen mit `photos` auf `.photo` — und damit fiel die ganze Mediathek unter `MediaLibrary.isSupported` heraus: keine Reihe auf der Startseite, kein Eintrag in der Mediathekenleiste, nicht einmal eine Zeile in der Auswahl für den Aufmacher. Aus Sicht der App gab es sie nicht. Dass Fotos im Namen stehen, macht den Inhalt nicht zu Fotos. `photos` bleibt bei den Fotos, `homevideos` ist jetzt `.other` — wie alles, was der Server nicht einsortiert. Die Zuordnung steht dafür nicht mehr mitten in `libraries()`, sondern als eigene Funktion mit Tests. Sie entscheidet mehr, als sie aussieht: was hier als `.photo` oder `.music` landet, ist in der App unsichtbar, und das sieht aus wie ein Server, der nichts liefert — nicht wie eine Zuordnung, die zu scharf ist. Drei Tests halten es fest, darunter der Fall ohne Angabe: eine gemischte Mediathek meldet gar keine Art und muss trotzdem bleiben. iOS und tvOS bauen, 472 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 10:25:16 +02:00
ScarriffleandClaude Opus 5	19c9dc843c	„Aus Weiterschauen entfernen" tut jetzt etwas — und man kann es sehen ... Der Knopf war wirkungslos, und zwar aus zwei Gründen, die beide auf dasselbe hinauslaufen: er war nie geprüft worden. **Der Weg war falsch.** Die Methode las erst ein Benutzerdatenblatt über `GET /Users/{id}/Items/{id}/UserData`, änderte es und schrieb es zurück. Diese Stelle war die **einzige im ganzen Projekt**, die ein solches Blatt eigens liest — überall sonst kommt es am Titel mit. Es gab also kein zweites Beispiel, an dem der Weg je funktioniert hätte, und ein 404 beendete die Sache, bevor überhaupt etwas geschrieben wurde. Jetzt wird das Blatt **gebaut**, nicht erfragt: „gesehen", „Favorit" und die Zählung stehen am Titel, den der Aufrufer ohnehin in der Hand hat — deshalb nimmt `removeFromContinueWatching` jetzt den Titel statt nur seiner Kennung. Gelesen wird trotzdem noch, aber unverbindlich: gelingt es, bleiben auch Felder erhalten, die diese App gar nicht kennt. Und geschrieben wird über beide Wege — erst der gebündelte `/UserItems/{id}/UserData`, bei einem 404 der ältere. Welcher gilt, hängt an der Serverfassung. **Und man konnte es nicht sehen.** Die Attrappe kannte die Route nicht; ihr Auffangzweig antwortete auf jeden Schreibversuch mit Status 200, und die Weiterschauen-Reihe war fest verdrahtet. Der Aufruf gelang also immer und änderte nie etwas — genau das Bild eines kaputten Knopfes, nur aus einem anderen Grund. Genau deshalb ist der Fehler durchgerutscht. Sie führt jetzt echte Benutzerdatenblätter, beantwortet beide Wege und liefert unter „Weiterschauen" nur noch, was eine gemerkte Stelle grösser null hat. Unter `/__userdata` steht, was geschrieben wurde und wohin. Gemessen im Simulator, nach einem Tipp auf den Eintrag: /UserItems/m2/UserData {"Played":false,"IsFavorite":false,"PlaybackPositionTicks":0,…} Danach ist „Weiterschauen" leer und die Reihe verschwindet von der Startseite. **Zwei Dinge, die danach trotzdem auffallen können**, und beide sind keine Fehler: Jellyfins „Als Nächstes" führt angefangene Folgen mit, eine entfernte Folge kann dort wieder auftauchen. Und bei zusammengelegten Reihen stehen auch Folgen ohne gemerkte Stelle — dort gibt es nichts zu entfernen, und der Eintrag fehlt. Plex bleibt unberührt: der Weg dort war in Ordnung und bekommt nur die neue Form. iOS und tvOS bauen, 469 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 09:30:20 +02:00
ScarriffleandClaude Opus 5	ac62e8bf19	Der Aufmacher war weg, weil die Mediathek unterwegs verlorenging ... Zwei Schalter, die im selben Bildschirm untereinander stehen, ergaben zusammen gar keinen Aufmacher mehr: „Gesehenes aus Neuzugängen ausblenden" und eine angehakte Mediathek. Der Grund steht in `HomeFeed.prepared`. Der Zweig für das Ausblenden baut die betroffenen Reihen neu — und baute sie **ohne `libraryID`** neu, weil der neue Parameter dort nicht mitgegeben war. Getroffen hat es dabei ausgerechnet die Reihen `latest.<mediathek>`, die als einzige überhaupt eine tragen. Danach warf der Filter des Aufmachers jede Reihe ohne Mediathek weg, und übrig blieb nichts. Dasselbe an zweiter Stelle: `combiningContinueRows` verlor `libraryID` **und** `moreKey` — Letzteres ein eigener, älterer Fehler, durch den bei zusammengelegten Weiterschauen-Reihen „Alle anzeigen" wegfiel. **Dazu eine Regel, die ich zurücknehme.** Gestern stand hier: trifft die Auswahl nichts, bleibt nichts. Das war als Ehrlichkeit gedacht und ist in der Praxis der schlechtere Fehler — ein Aufmacher, der lautlos verschwindet, wird überall gesucht, nur nicht in einer Einstellung zwei Bildschirme weiter. Trifft die Auswahl keine einzige Reihe, gilt sie jetzt als wirkungslos. Das deckt auch den Fall ab, dass eine gespeicherte Kennung nach einem Serverwechsel ins Leere zeigt. Und damit solche Kennungen nicht unsichtbar weiterwirken, werden sie beim Öffnen des Bildschirms gegen die vorhandenen Mediatheken abgeglichen — vorher standen sie in keiner Zeile und liessen sich nicht abwählen. Geprüft im Simulator: „Gesehenes ausblenden" an, „Filme" angehakt — der Aufmacher ist da und zeigt einen Film. Vorher: nichts. iOS und tvOS bauen, 469 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 09:26:18 +02:00
ScarriffleandClaude Opus 5	3a6a6c4242	Intro und Abspann bei Jellyfin, und drei Dinge aus dem Gebrauch ... **Intro überspringen gab es für Jellyfin nie.** Der Knopf, die Marken, das automatische Überspringen, die Einstellungen dazu — alles stand seit Langem im Player und auf dem Fernseher. Nur kam bei Jellyfin nie eine Marke an: `JellyfinItem+Media.swift` setzte `markers: []`, weil Jellyfin sie nicht am Titel liefert. Seit 10.10 gibt es `/MediaSegments/{itemId}`, gefüllt von einem Anbieter im Server wie dem Intro-Skipper. Die Anfrage läuft **neben** dem Abruf des Titels, nicht danach — sonst wartete die Detailseite zweimal. Zwei Dinge, die sonst eine Stunde kosten: `includeSegmentTypes` muss **zweimal** stehen, nicht einmal mit Komma (mit Komma antwortet Jellyfin mit null Treffern), und die Abfrage wirft nicht. Ein Server ohne Anbieter antwortet leer, einer vor 10.10 mit einem 404 — und ein Film ohne Intro ist kein Fehler, sondern der Normalfall. Geprüft im Simulator: die Attrappe meldet jetzt Segmente, und im Player steht „Intro überspringen". --- **„Aus Weiterschauen entfernen".** Eine halbe Stunde gesehen und keine Lust mehr — der Titel ist weder gesehen noch ungesehen, er soll nur nicht ewig oben stehen. Beide Server können es, auf verschiedenen Wegen: - **Plex** hat einen eigenen: `PUT /actions/removeFromContinueWatching`. **Nicht** `/:/unscrobble` — das setzt zugleich auf ungesehen. - **Jellyfin** hat keinen. Was es gibt, ist das Benutzerdatenblatt; die Liste führt, was eine gemerkte Stelle grösser null hat. Also wird das Blatt gelesen, bekommt eine Null und geht so, wie es war, zurück. **Erst lesen, dann schreiben**, weil dort auch „gesehen", „Favorit" und die Bewertung stehen — wer seinen Favoriten verliert, weil er einen Film aus einer Liste genommen hat, sucht den Grund nie dort. Der Eintrag erscheint nur, wenn es eine gemerkte Stelle gibt. --- **Die Mediatheken für den Aufmacher taten zu wenig.** Die Regel „Reihen ohne Mediathek bleiben immer drin" war freundlich gemeint und falsch: bei „nur Filme" stand weiter eine Serie oben, weil sie aus „Weiterschauen" kam. Gemessen und nicht vermutet — es lag nicht am Zeitfenster der Auswahl, wie zuerst angenommen. Jetzt gilt: ist etwas gewählt, speist sich der Aufmacher **nur** daraus. Wer Weiterschauen oben haben will, wählt keine Mediathek. Der Hinweis unter der Auswahl sagt das auch. --- **Der „Bearbeiten"-Knopf stand über allem und tat dort nichts.** Er gilt nur für die Reihen; jetzt steht er an deren Überschrift. --- Die Attrappe kann drei Dinge mehr, sonst wäre nichts davon prüfbar: Segmente, `parentId` bei den Neuzugängen (vorher stand in jeder Mediathek dasselbe) und damit überhaupt eine Mediathekenauswahl, die man ansehen kann. iOS und tvOS bauen, 468 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 08:47:06 +02:00
ScarriffleandClaude Opus 5	dc93d6e22e	Der Aufmacher lässt sich auf Mediatheken einschränken ... Mehrfachauswahl in den Einstellungen unter „Startseite": welche Mediatheken den Aufmacher speisen dürfen. Haken statt Auswahlliste — eine Liste könnte nur eine, und „keine" wäre dort ein Eintrag, den man versehentlich trifft. Dafür musste eine Reihe sagen können, woher sie kommt: `MediaRowGroup` trägt jetzt eine `libraryID`. Jellyfin setzt sie an den „Neu in …"-Reihen — die baut die App ohnehin je Mediathek. Zwei Regeln, und beide sind Entscheidungen, keine Nebenwirkungen: **Leer heisst alle.** Wer nichts ankreuzt, meint „mir ist es gleich", nicht „nimm nichts". Ein leerer Aufmacher wäre der Fehler, den niemand mit dieser Einstellung in Verbindung brächte. **Reihen ohne Mediathek bleiben immer drin.** Weiterschauen, Als Nächstes und Favoriten gehen quer durch alle, und aus welcher Mediathek eine angefangene Folge stammt, sagt der Server an keiner Stelle. Sie wegzuwerfen hiesse, jemandem das Angefangene zu nehmen, weil er „Musikvideos" abgewählt hat. Der Hinweis unter der Auswahl sagt das auch dem, der nicht in den Quelltext sieht. Eingeschränkt wird **nur der Aufmacher**, nicht die Startseite: die Reihe selbst bleibt stehen. Wer sie ganz loswerden will, blendet sie aus — das ist eine andere Frage und hat ihren eigenen Schalter. Fünf Tests an `HeroSelection.rows(_:limitedTo:)` halten die Regeln fest, darunter der Fall einer gespeicherten Kennung, die es nicht mehr gibt. **Plex bleibt aussen vor:** dort kommen die Reihen als fertige Hubs vom Server, und `librarySectionID` wird in `PlexHub` nicht gelesen. Die Auswahl schränkt dort also nichts ein. Nachzuholen, wenn Plex wieder dran ist. iOS und tvOS bauen, 468 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 08:24:09 +02:00
ScarriffleandClaude Opus 5	9e7f3393b4	DTS, TrueHD und Vorbis gehen jetzt an den Server statt an VLC ... Bisher entschied der Decider: steht nur die Schachtel im Weg, wird umgepackt — stimmt ein Codec nicht, geht es an VLC. Das war beim Ton zu grob gedacht. Beim Umpacken nennt das Geräteprofil dem Server, was ankommen darf: "VideoCodec": "h264,hevc" "AudioCodec": "aac,ac3,eac3,mp3" Trifft ein Strom eine dieser Angaben, kopiert der Server ihn; trifft er sie nicht, rechnet er **genau diesen einen** um. Eine Matroska mit HEVC und DTS braucht also kein VLC: das Bild geht Byte für Byte durch, und nur die Tonspur wird nach AC3 oder AAC kodiert. Das kostet Tonqualität und sonst nichts. Die Bedingung heisst deshalb nicht mehr „nur die Schachtel", sondern „das Bild bleibt": Container und Ton dürfen im Weg stehen, der Videocodec nicht. Dazu musste die Prüfung der Schachtel aufhören, sich immer zu stellen — eine MP4 mit DTS stand mit einem reinen Tonhindernis da und fiel trotzdem durch die Liste umpackbarer Container. **Der grössere Gewinn liegt auf dem Apple TV.** Dort gibt es VLC nicht, und bisher landete eine Datei mit DTS-Ton beim vollen Neurechnen — Bild inbegriffen, obwohl mit dem Bild nichts war. Jetzt bleibt das Bild unberührt. Auf iPhone, iPad und Mac verhält sich derselbe Film jetzt gleich, und zwar über AVPlayer: mit Bild-in-Bild, AirPlay und Sperrbildschirm, die es auf dem VLC-Weg nie gab. Geprüft im Simulator gegen die Attrappe mit `--vlc` (meldet DTS): der Film läuft, und in der Leiste steht jetzt der AirPlay-Knopf, der vorher fehlte — der sichtbarste Beleg dafür, dass AVPlayer spielt und nicht VLC. „Umgepackt" und „umgepackt, Ton umgerechnet" sind in den technischen Infos und in der Diagnose auseinandergehalten. Ein Weg, der den Ton neu kodiert, darf nicht „ohne Neukodierung" heissen. Was bleibt bei VLC: nicht unterstützte **Bild**codecs, allen voran AV1, und Dateien, die der Server noch nicht untersucht hat. Dafür gäbe es nur das volle Neurechnen — eine eigene Entscheidung, nicht diese. iOS und tvOS bauen, 463 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 07:46:39 +02:00
ScarriffleandClaude Opus 5	3ed682dd00	Der Sicherheitsrand am Bild war falsch — er schützte vor nichts ... Eingepasst bekam das Bild ein Polster in Grösse des Sicherheitsrandes, damit es nicht unter die Dynamic Island läuft. Nachgerechnet hält das nicht. Querformat auf einem Pro Max: 956 × 440 Punkt. Ein Bild in 16∶9 wird bei voller Höhe 782 Punkt breit — es bleiben 87 Punkte Balken auf jeder Seite, und die Island braucht 62. Das Bild kommt ihr von selbst nicht nahe. Das Polster hat also nichts abgewehrt und dabei vierzig Punkte Höhe gekostet, also jedes zehnte Bildpunktband: vorher 695,7 × 400 pt Balken 130,0 / 130,3 jetzt 765,3 × 440 pt Balken 95,3 / 95,3 Beides über VLC gemessen, dieselbe Datei, dieselbe Lage. Erst was breiter ist als der Schirm (2,17∶1) läuft an die Kanten — bei 21∶9 über die ganze Breite, und dann liegt ein Streifen hinter der Island. Dafür ist der Zoomknopf da. Ein Film, der nie an den Rand darf, wäre der schlechtere Tausch: er kostet bei *jeder* Datei Höhe, um bei wenigen einen Streifen zu retten. `EdgeInsets.symmetrical` fällt damit weg, samt seiner fünf Tests. Es hatte genau eine Aufgabe — ein unsymmetrisches Polster mittig zu halten —, und das Polster gibt es nicht mehr. Eine geprüfte Funktion, die niemand ruft, ist trotzdem nur Ballast. iOS und tvOS bauen, 460 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-10-01 07:33:18 +02:00
ScarriffleandClaude Opus 5	b0db4f8f5f	Bei VLC sass das Bild nie richtig — und der Knopf wirkte nie ... Zwei Fehler, die dieselbe Ursache haben: alles, was über VLC läuft, ging an der Bildebene vorbei, an der die App gedreht hat. **Das Bild sass nicht mittig.** Nicht ein paar Punkte daneben — gemessen eine Anzeigefläche von 1200×480 Punkt in einer Zeichenfläche von 711×400, unten rechts angeschlagen, im falschen Seitenverhältnis. Der Grund steht im Vertrag von `VLCDrawable`: VLCKit fragt die Grösse **einmal** beim Anlegen ab und überlässt seine Anzeigefläche danach der Autoresizing-Maske. Eine Maske hält aber den Unterschied fest, nicht das Verhältnis — was beim Anlegen zu gross war, bleibt für immer um denselben Betrag zu gross. Und angelegt wird sie mitten in der Drehung ins Querformat, während SwiftUI sie einblendet: also regelmässig falsch. Die Zeichenfläche ist jetzt eine eigene Klasse, die ihrer Anzeigefläche bei jedem Layout wieder die eigene Grösse gibt. Danach gemessen: 695,7 × 400 Punkt, Rand links 130,0, rechts 130,3 — mittig. **Der Knopf für einpassen/füllen tat nichts.** Er schrieb `videoGravity` auf eine `AVPlayerLayer`, die bei VLC gar nicht im Baum hängt. Die Einstellung geht deshalb jetzt durch die Engine: `setVideoFit` am Protokoll, beim Systemplayer eine Voreinstellung, die nichts tut — dort macht es die Bildebene —, bei VLC `videoFitMode`. `smaller` heisst bei libvlc „fit inside", `larger` „fit outside". Gemessen, im Querformat auf einem Pro Max, über VLC: eingepasst 695,7 × 400 pt Rand l/r 130,0/130,3 o/u 20,0/20,0 füllend 935,3 × 440 pt Rand l/r 10,3/ 10,3 o/u 0,0/ 0,0 **Zurückgenommen:** im Kommentar an `videoFit` stand, ein `didSet` auf einer `@Observable`-Klasse werde nicht gemeldet. Das stimmt nicht — `HomeLayoutSettings` lebt davon. Ein Kommentar, der einen falschen Mechanismus behauptet, schickt den nächsten in die falsche Richtung; jetzt steht der belegte Grund dort. Dazu, damit dieser Weg überhaupt prüfbar ist: die Attrappe meldet mit `--vlc` DTS-Ton. AVFoundation kann das nicht, also fällt die App auf VLCKit zurück. Die Beispieldatei bleibt dieselbe — geprüft wird der Weg, nicht der Ton. Ohne diesen Schalter ist der VLC-Zweig im Simulator gar nicht zu erreichen, und genau deshalb lagen beide Fehler so lange da. Ebenfalls dabei: `EdgeInsets.symmetrical` mit fünf Tests und das Polster im Player, das damit nicht mehr verschiebt statt einrückt. iOS und tvOS bauen, 465 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-30 21:05:57 +02:00
ScarriffleandClaude Opus 5	a1576921fd	Das Regal hatte seine eigene Transportsicherheit ... Die Plakate blieben weg, und der Grund stand nicht im Code, sondern daneben: eine App-Erweiterung hat ihre **eigene** Info.plist, und damit ihre eigene Transportsicherheit. Die Ausnahme fürs lokale Netz, die in der Info.plist der App seit jeher steht, gilt dort nicht. Ein Jellyfin im Heimnetz antwortet auf blankem HTTP. Jede Bildanfrage der Erweiterung lief damit gegen ATS — lautlos, ohne Fehler, ohne Eintrag. Das Regal blieb leer und sah aus wie „geht halt nicht". Dazu die richtige Plakatgrösse: 666×1000 statt 404×606, Apples Mass für die doppelte Auflösung. Für beide Stufen dasselbe Bild — ein Apple TV zeichnet das Regal ohnehin doppelt aufgelöst, und zwei Adressen abzulegen hiesse, dem Server zwei Grössen desselben Plakats abzuverlangen, damit eine davon nie gebraucht wird. Nicht nachgewiesen: dass es jetzt zeichnet. Das Regal erscheint nur, wenn die App in der **obersten** Reihe des Menüs steht und fokussiert ist, und den Fokus kann ich im Simulator nicht bewegen — tvOS nimmt keine Touch-Eingaben, und an die Simulator-App komme ich aus dieser Umgebung nicht heran. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 21:16:04 +02:00
ScarriffleandClaude Opus 5	6373566d1c	Suchen am Fernseher — und die Leiste, die es dafür braucht ... Das Backend konnte die Suche längst; es fehlte die Oberfläche. **`.searchable`, keine eigene Tastatur.** tvOS macht daraus einen eigenen Bildschirm mit Rastertastatur oben und Ergebnissen darunter — die Bedienung, die jeder von Apples Apps kennt. Etwas Eigenes zu bauen hiesse, sie nachzuahmen und dabei die Diktierfunktion zu verlieren. **Herausgelöst statt kopiert**, wie schon bei Start und Mediathek: `SearchFeed` trägt das Entprellen, die Mindestlänge und die zuletzt gesuchten Begriffe. Drei Stellen, an denen es nicht offensichtlich ist — und die dritte ist die wichtigste: geprüft wird auf `Task.isCancelled` und nicht auf `CancellationError`, weil eine abgebrochene Netzanfrage als Übertragungsfehler zurückkommt. Die naheliegende Prüfung lief ins Leere, und jeder Tastendruck leerte kurz die Liste. **Und erst jetzt eine Reiterleiste.** Bis hierher gab es genau einen Bildschirm, und eine Leiste mit einem Eintrag wäre Zierrat gewesen. Der Suchreiter trägt `role: .search`: tvOS stellt ihn dadurch ans Ende und gibt ihm die Lupe, dieselbe Stelle wie überall sonst. Keinen dritten Reiter für die Mediatheken — die stehen als Reihe auf der Startseite, und ein Reiter verspräche einen eigenen Bereich, hinter dem dasselbe Raster läge. Der offene Reiter wird ausdrücklich gehalten, nicht dem System überlassen: ein Link aus dem Regal über der App führt zur Startseite, und stünde gerade die Suche offen, passierte sichtbar nichts. Nebenbei bekommt die iOS-Suche einen Knopf zum Vergessen des Verlaufs. Wischen zum Löschen gab es dort, am Fernseher gibt es das nicht — und eine Liste, die sich nur auf einer Plattform leeren lässt, ist keine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 20:30:55 +02:00
ScarriffleandClaude Opus 5	5ee7bb4e6c	Lila statt Mint — die Farbe der Knöpfe passt zum Icon ... Die Akzentfarbe war Mint. Eine hübsche Farbe, die mit der Marke nur nichts zu tun hatte: das Plakat auf dem Homescreen ist violett, und die Knöpfe darin waren grün. `lilac` (#9B8AD4) ist die entsättigte Schwester desselben Violetts. Auf dem dunklen Grund erreicht sie 6,5:1 — die Palette verlangt 4,5:1, und ein Test hält das fest. Die Farbe steht in der Palette, nicht nur als Vorgabe: wer lieber Mint mag, findet es weiterhin in den Einstellungen. Geändert wird damit nur, womit eine frische Installation anfängt. Der Test, der die Vorgabe festhält, ist mitgeändert — genau dafür steht er da: ein Umsortieren der Palette soll sie nicht still verändern, ein bewusster Wechsel schon. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 20:27:20 +02:00
ScarriffleandClaude Opus 5	e801502c7a	Ein Regal über der App — und ein Weg aus dem Player heraus ... **Das Regal.** Wer im tvOS-Menü über der App steht, sah bisher das Icon noch einmal gross. Jetzt stehen dort „Weiterschauen", „Als Nächstes" und die Neuzugänge als Plakate, mit Fortschrittsbalken; ein Druck spielt ab, ein Wisch nach unten öffnet die Detailseite. **Warum es dafür eine App-Gruppe braucht.** Das Regal zeichnet eine eigene Erweiterung, also ein anderer Prozess mit eigener Sandbox — und tvOS ruft sie auf, während die App **nicht** läuft, mit weniger als einer Sekunde Zeit. Kein Netzabruf, keine Anmeldung, kein Blättern. Also legt die App beim Laden der Startseite hin, was das Regal braucht, und sonst nichts: Titel, Bildadresse, Kennung, Fortschritt. Eine Datei, ein `JSONDecoder`, fertig. Die Bildadressen tragen den Zugangsschlüssel, weil Jellyfin ihn für Bilder verlangt und die Erweiterung ihn sonst nirgends herbekäme. Die Datei liegt in der App-Gruppe — erreichbar für die App und ihre Erweiterungen, für sonst niemanden. Der Schlüsselbund bleibt, wo er ist. **Und der Fehler, den du gefunden hast.** Solange der Stream noch ausgehandelt wurde, gab es keinen Weg zurück: schwarzes Bild, Kreisel, und der Menü-Knopf tat nichts. `AVPlayerViewController` fängt ihn nämlich selbst ab — aber erst, wenn er einen Player mit einem Item hat, und genau den gibt es in dem Moment noch nicht. Der Griff liegt jetzt eine Ebene darüber, wo es ihn vom ersten Bild an gibt. Doppelt ist er nicht: greift Apples Player zu, kommt der Befehl dort gar nicht mehr an. **Was am Gerät noch offen ist.** Die App-Gruppe muss im Entwicklerkonto eingetragen sein, sonst bleibt das Regal leer — im Simulator legt das System sie von selbst an, auf einem echten Apple TV nicht. Geprüft ist, dass die App die Datei schreibt (drei Reihen, richtige Adressen) und dass tvOS das Schema kennt. Dass das Regal beim Darüberstehen auch zeichnet, lässt sich ohne Fernbedienung nicht auslösen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 20:14:38 +02:00
ScarriffleandClaude Opus 5	12bfc9e530	Abspielen am Fernseher — mit Apples Player und unseren Spuren ... Schritt sieben. Wiedergabe, Spurwahl, Titelzeile, „Intro überspringen". **Die schwierige Stelle war die Spurwahl.** Unsere Ton- und Untertitelwahl geht als `audioStreamIndex` an Jellyfin und verlangt bei einem Transcode einen **neuen Stream**. Apples eingebauter Spurwähler zeigt dagegen die Auswahlgruppen des **laufenden** Streams — beim Transcode genau eine. Er ist die richtige Oberfläche für die falsche Liste. Unsere Menüs sitzen deshalb über `transportBarCustomMenuItems` daneben; `customInfoViewControllers` wäre falsch, denn die Tonspur ist ein Bedienelement der Wiedergabe und kein Begleitmaterial. **Der Neuaufbau wird angesagt, nicht erklärt.** Jeder Eintrag, der Sekunden mit schwarzem Bild kostet, trägt das als Untertitel — vorher, nicht hinterher. Wer drückt, sieht den Haken sofort wandern, weil das Menü sich schliesst und darin kein Platz für einen Kreisel ist. Das schwarze Bild deckt eine Überlagerung in `contentOverlayView` zu, die hinter den Bedienelementen liegt und keinen Fokus nimmt — `customOverlayViewController` täte beides nicht und machte die Fernbedienung währenddessen tot. Und solange umgebaut wird, sind alle Einträge gesperrt: sonst räumt `restart()` eine Engine ab, die eine andere gerade baut. **Die Regel dahinter ist jetzt prüfbar.** „Wann kostet ein Spurwechsel einen Neuaufbau" lag bisher mitten im Vollzug von `selectAudioStream` und liess sich nur an einem echten Server mit mehreren Tonspuren auslösen. Als `TrackMenu` steht sie neben den übrigen Entscheidungsregeln, mit sieben Tests — darunter der Fall, auf den der Kommentar dort seit jeher hinweist: stimmt die Spurzahl nicht überein, ist die Zuordnung über die Reihenfolge falsch, und es muss neu aufgebaut werden. **Zwei stille Fehler nebenbei.** Die Tonsitzung stand hinter `#if os(iOS)` und wäre auf tvOS nie gesetzt worden — verfügbar ist sie dort seit 9.0, man hätte es nur daran gemerkt, dass sich die Wiedergabe gegen anderen Ton nicht durchsetzt. Und `PlayerModel.downloads` ist jetzt optional statt eines leeren Koordinators: ein leerer bräuchte einen `ModelContainer`, und der ist das Einzige, wofür diese App SwiftData benutzt. **Belegt statt vermutet.** Im Simulator lief die Wiedergabe gegen die Attrappe, und die Titelzeile zeigte „Unbekannt". Statt an AVKit zu drehen, hat ein Protokolleintrag die Frage beantwortet: `externalMetadata` wird gesetzt, der Wert stimmt, und „Unbekannt" ist wörtlich das, was die Attrappe für unbekannte Kennungen liefert. Geblieben ist davon nur die Erkenntnis, dass die Beschriftung auf das Item warten muss — beim Austausch des Players gibt es noch keines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 19:55:02 +02:00
ScarriffleandClaude Opus 5	87f23afe90	Die Startseite am Fernseher — und die Ladeschicht nur einmal ... Aufmacher, Reihen, Mediatheken, Raster. Der sichtbare Teil ist neu; der Teil darunter ist derselbe wie am Telefon, und das war die eigentliche Arbeit. **Herausgelöst statt kopiert.** `HomeFeed` und `LibraryFeed` tragen jetzt, was vorher in `HomeView` und `LibraryView` stand: laden, ordnen, den Aufmacher auslosen, den Zwischenspeicher abziehen, entdoppeln, nach einem Fehlschlag sperren. Das zu kopieren wäre der schlimmste Ausgang dieses Vorhabens gewesen — an mindestens drei dieser Stellen klebte schon je ein Fehler, der sich als „es sind nicht alle Filme drin" äusserte und sonst nichts. Einer davon, das Los des Aufmachers an der Position statt am Titel, wäre in einer Kopie ein zweites Mal zu finden gewesen. Mitgewandert sind `rowTitle`, `rowArtworkPath`, `posterArtworkPath`, `runtimeLabel` und `HeroArtwork`: reine Ableitungen, die in einer Ansichtsdatei lagen und deshalb nur das Telefon übersetzte. **Nachgeladen wird am Fokus, nicht am Erscheinen.** Die alte Regel hiess „die letzten fünf" und hing daran, dass eine Kachel sichtbar wird. Beim ersten Zeichnen erscheinen aber alle sechzig, auch die letzten fünf — das Nachladen lief sofort los statt beim Blättern. Auf einem Raster aus sechs Spalten sind fünf Einträge ausserdem nicht einmal eine Zeile. `PagingWindow` rechnet deshalb in Zeilen; sechs Tests halten es fest, darunter der Fall, der die alte Regel entlarvt. **Der Fokus setzt den Aufmacher.** Wer durch „Zuletzt hinzugefügt" wandert, sieht oben, was er gerade anschaut. Kein Wechsel im Sieben- sekundentakt wie am Telefon: vor einem Fernseher wäre ein Bild, das sich von allein austauscht, während man es liest, eine Zumutung. **Drei Dinge, die erst der Simulator zeigte.** Die Seiten müssen bildfüllend laufen, weil ein Aufmacher, der achtzig Punkte vor der Bildschirmkante aufhört, nach Fehler aussieht — also trägt `screenMargin` auf tvOS den Überscan mit. Die Karten brauchen einen Fokus-Rückruf, weil `\.isFocused` den nächsten fokussierbaren Vorfahren meint und das in einer Reihe aus Karten nicht verlässlich die Karte ist. Und der Bau scheiterte an „Unable to resolve module dependency: VLCKit" — der Abhängigkeits- Sucher prüft `canImport(FlixyVLC)` auch für ein Ziel, das es nie verlinkt. Ein `&& !os(tvOS)` genügt; das Paket selbst bleibt unverändert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 19:36:49 +02:00
ScarriffleandClaude Opus 5	22f824b000	Die Ränder kommen jetzt von der Stelle, die sie kennt ... Mein voriger Versuch war an der Quelle falsch, nicht an der Rechnung. **Was ich gebaut hatte:** die Sicherheitsränder in `RootView` messen und über die Umgebung an den Player reichen. Gemessen in einer Ansicht, angewendet in einer anderen, über eine Drehung hinweg — drei Gelegenheiten, daneben zu liegen. Im Simulator ging es gut, auf dem Gerät nicht: dort standen im Querformat links 75 und rechts 28 Punkt Rand, und der Untertitel wurde von der Bildschirmkante abgeschnitten. **Warum SwiftUI hier nicht hilft.** Der Sicherheitsrand ist dort kein Wert, den man erfragt, sondern einer, den man verbraucht: wer ihn respektiert, sieht null, und wer ihn mit `ignoresSafeArea` überschreitet, sieht danach ebenfalls null. Beide Auswege habe ich durchgespielt und beide gemessen. Nimmt man der Ansicht das `ignoresSafeArea`, sitzen die Knöpfe richtig — aber die Bildfläche verliert es mit, und das Bild ist im Querformat um die Notch-Breite schmaler. Schiebt man einen `GeometryReader` dazwischen, passiert dasselbe. **Das Fenster weiß es immer**, in der richtigen Ausrichtung und in dem Moment, in dem gefragt wird. `ScreenSafeArea` ist die eine Stelle in dieser App, die so fragt, und die eine, an der es keinen SwiftUI-Weg gibt. Nachgeholt wird der Wert bei jeder Änderung der Fläche — das ist genau der Moment des Drehens. Nachgemessen im Simulator gegen die Jellyfin-Attrappe: im Querformat meldet das Fenster 0/62/62/20, und damit stehen Kopfzeile, Schieberegler und Zeitangaben vollständig im sichtbaren Bereich, während das Bild bis an die Kanten reicht. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 17:32:50 +02:00
ScarriffleandClaude Opus 5	6326c8c24c	Ein Apple-TV-Target, und es zeigt schon etwas ... Das leere Gerüst: eigene Wurzel FlixyTVApp, eigenes Target FlixyTV in project.yml, eigener Asset-Katalog. Es beweist Target, Icon, Signierung und Paketauflösung auf einen Schlag — bevor eine Zeile Logik daran hängt. **Das Icon von Hand gebaut.** Icon Composer deckt iOS, macOS und watchOS ab, tvOS nicht: der Fernseher verlangt gestapelte Bilder, damit die Parallaxe beim Wischen etwas zu bewegen hat. Zwei Ebenen aus derselben Marke — Verlauf hinten, Dreieck vorn —, dazu App-Store-Icon und beide Top-Shelf-Bilder. Ohne das breite lehnt App Store Connect den Upload mit 90513 ab. **Zwei Annahmen aus dem Plan haben sich beim Bauen erledigt.** PlexWebAuthenticator übersetzt nicht: ASWebAuthenticationSession steht zwar im tvOS-SDK, aber presentationContextProvider, cancel() und der Rest sind dort nicht verfügbar. Der Typ bleibt trotzdem stehen — als Attrappe, die sofort „ging nicht" meldet. Ihn herauszuschneiden hiesse, die Zustandsmaschine der Anmeldung für eine Plattform zu spalten, die diesen Zweig nie betritt. Dieselbe Bauform wie bei OrientationLock. NowPlaying wartet auf den Player in Schritt sieben. **Und eine Messung statt einer Vermutung.** Der Plan führte zwei offene Annahmen über den Sicherheitsrand. Der Simulator beantwortet beide: SwiftUI legt ihn von selbst an, und er misst sechzig oben und unten, achtzig seitlich — nicht neunzig. Nutzfläche 1760×960. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 17:18:03 +02:00
ScarriffleandClaude Opus 5	6010229b80	Die Pakete wissen jetzt, was ein Fernseher ist ... Schritt eins zur Apple-TV-Fassung: nichts davon ist sichtbar, aber ohne das lässt sich für tvOS nicht einmal übersetzen. **Der stille Fehler zuerst.** `FlixyPlatform.isMac` hatte einen `#else`-Zweig, der `true` zurückgab — eine Antwort auf eine Frage, die niemand gestellt hatte. Auf tvOS fiel er dort hindurch: kein Übersetzungsfehler, keine Warnung, nur ein Fernseher, der sich für einen Mac hielt. Jetzt steht dort `#error`. Die nächste Plattform bricht den Bau ab und verlangt eine Entscheidung, statt sich eine auszusuchen. Ein Test hält fest, dass nicht beides zugleich gelten darf; er hätte genau diesen Fehler gefangen. **Ein echter Übersetzungsfehler**, und er lag an der Reihenfolge: `UIPasteboard` steht hinter `canImport(UIKit)`, und das ist auf tvOS wahr. Der tvOS-Zweig steht deshalb jetzt davor — ein Fernseher hat ohnehin nichts, wohin man etwas einfügen könnte. **Drei Vermutungen waren falsch**, nachgeschlagen im tvOS-SDK statt geraten: `presentationDetents` gibt es dort seit tvOS 16 (übersetzt, bewirkt nur nichts — jetzt steht es ausdrücklich da), `.topBarTrailing` seit 14.0, und `isMac` hatte acht Fundstellen in fünf Dateien, nicht fünfzig in siebenundzwanzig. **Schrift und Abstände** bekommen einen eigenen Zweig statt durchzufallen. Nicht feste Grössen: Dynamic Type gibt es auf tvOS auch, und dass `body` dort grösser ausfällt, ist der Sinn der Sache. Falsch war nur die Zuordnung der Rollen — die Skala ist anders gespreizt, und eine Beschriftung in `subheadline` unter einem Plakat ist aus drei Metern Zierrat. Der Aufmacher geht auf `.title`, weil UIKit `largeTitle` auf tvOS gar nicht kennt und nirgends steht, was SwiftUI daraus macht. `screenMargin` steht auf 48 und nicht auf 90: die neunzig Punkte des Überscan-Bereichs liefert das System als Sicherheitsrand, und wer sie hier aufschlägt, hat hundertachtzig. **Zwei Dinge, die sich erst beim Bauen zeigten.** `FlixyDownloads` übersetzte nicht — `volumeAvailableCapacityForImportantUsage` gibt es auf tvOS nicht. Das Paket wird dort trotzdem mitverlinkt, damit `PlayerModel` den Koordinator nennen darf, ohne dass zweitausend Zeilen Wiedergabelogik von `#if` durchzogen werden; angelegt wird nie einer. Und `FlixyProbe` liess das ganze Paket scheitern: ein Kommandozeilenwerkzeug mit `getpass` und `Host`, das auf einem Fernseher nie laufen sollte, hielt den Bau für alle anderen auf. Es ist jetzt ausdrücklich macOS-only. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-29 17:09:18 +02:00