Der Anmeldebildschirm kannte nur Plex. JellyfinKit war fertig, aber von der
App aus nicht erreichbar — „ich sehe nix von Jellyfin".
Quick Connect steht vorn: der Server nennt einen sechsstelligen Code, den man
in einem bereits angemeldeten Client bestätigt. Das Passwort erreicht Flixy
dabei nie, dieselbe Zusage wie bei Plex. Benutzername und Passwort sind der
Rückfall für Server, auf denen Quick Connect abgeschaltet ist; das Passwort
wird dann für die Dauer einer Anfrage gehalten und danach weggeworfen.
Die Adresse wird nicht erraten, sondern durchprobiert. „192.168.1.50" kann
alles Mögliche heißen, und die Reihenfolge ist der Kern von JellyfinAddress:
eine IP-Adresse im eigenen Netz spricht fast nie HTTPS, ein Domänenname fast
immer. Andersherum wartet man bei jedem Server ohne Zertifikat erst auf eine
Zeitüberschreitung.
Die Sitzung hält von hier an einen Server hinter dem neutralen Vertrag, nicht
mehr einen Plex-Server. Die Ansichten haben das nicht gemerkt — genau dafür
war MediaKit da. Dabei fällt ab, was Jellyfin kann und Plex nicht: Favoriten
stehen im Aktionsmenü, sobald der Server sie kennt, Sterne nur dort, wo es
sie gibt.
Was noch nicht geht und deshalb auch nicht behauptet wird: Wiedergabe und
Live-TV sprechen weiter unmittelbar mit Plex. Bei Jellyfin verschwindet der
Live-TV-Eintrag aus der Seitenleiste, und der Player sagt, dass die
Wiedergabe der nächste Schritt ist, statt „Server nicht erreichbar" zu
melden — er ist ja erreichbar.
Nebenbei zwei Stellen, die der Übersetzer aus Plex hinterlassen hat:
`catch is CancellationError` griff seit den getippten Fehlern nie mehr, weil
eine abgebrochene Netzanfrage als Übertragungsfehler zurückkommt; und das
Ersatz-Hintergrundbild einer Folge war toter Code, weil die linke Seite des
`??` gar nicht optional war.
TokenStore wandert nach MediaKit — Tokens sind nichts Plex-Eigenes. Die
Konten sind nach Server getrennt, damit ein späteres Umschalten nicht jedes
Mal eine neue Anmeldung kostet; „Abmelden" räumt trotzdem beide ab.
248 Tests grün.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Unterschied zwischen 400 und 200 war ein einziger Parameter:
…&protocol=hls&X-Plex-Token=… → 400
…&protocol=hls&X-Plex-Client-Profile-Name=Chrome&… → 200
Flixy hat immer nur `X-Plex-Client-Profile-Extra` geschickt. Das
**erweitert** ein Profil, es ersetzt keins — ohne Basis gibt es nichts zu
erweitern, und der Server kann keine Entscheidung bilden. Seine Antwort
darauf ist eine nackte 400 ohne jeden Hinweis.
Das betrifft alles, was durch den Transcoder geht: die Qualitätswahl im
Player, komprimierte Downloads und Live-TV. Bei Filmen fiel es nicht auf,
weil dort DirectPlay greift.
„Chrome" als Basis, weil dieses Profil auf jedem Server vorhanden ist und
genau das kann, was AVPlayer kann: HLS mit H.264 und AAC. Die Feinheiten
für iOS stehen weiterhin im Zusatz.
Gefunden wurde es, indem die Anfragen Angabe für Angabe aufgebaut wurden,
bis eine davon umschlug — nicht durch Nachdenken.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zehn Runden lang habe ich die Antwort gelesen, ohne sie anzusehen:
<html><head><title>Bad Request</title></head><body><h1>400 Bad
Request</h1></body></html>
So antwortet Plex nicht. Plex schickt XML oder JSON. Das ist die
Standardseite eines Webservers. Dazu passt, dass ping und stop mit 404
antworten, obwohl es sie in jedem Plex gibt.
Die Anfragen erreichen Plex also womöglich gar nicht, sondern werden
davor abgewiesen — vom Router, vom Webserver des NAS oder einem Proxy.
Das erklärt, warum wirklich jede Variante scheitert, auch die minimalste,
und warum eine gewöhnliche Datei genauso betroffen ist.
Der Probe zeigt jetzt alle Wege zum Server und nimmt mit `--local` den
lokalen. Geht es dort, liegt es an dem, was von außen dazwischensteht,
und nicht an Flixy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Server sagt transcoderVideo=1 — er kann umrechnen. Damit ist auch
diese Ausrede weg, und es liegt an meiner Anfrage.
Zwei Stellen, an denen ich es mir zu leicht gemacht habe. Der Titel für
die Gegenprobe kam aus den Startseiten-Reihen, und dort stehen auch
Einträge von plex.tv, deren Kennung kein Schlüssel dieses Servers ist.
Mit so einem Eintrag prüft die Gegenprobe gar nichts — sie kommt jetzt
aus einer echten Mediathek, und vorher wird nachgesehen, ob der Eintrag
überhaupt existiert.
Und die Antwort der Live-Sitzung war bei 700 Zeichen abgeschnitten,
ausgerechnet dort, wo `Part` anfängt — an der einzigen Stelle, die zählt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Jede Variante scheitert, auch „nur Pfad und Token". Damit ist es kein
Parameter — es ist der Endpunkt.
Also die Frage eine Ebene höher: `ping` und `stop` gehören zu derselben
Familie und brauchen nur eine Sitzungskennung. Antworten auch sie mit
400, ist nicht die Anfrage falsch, sondern der ganze Zweig nicht da.
Dazu zwei Gegenkontrollen von Dingen, die nachweislich gehen: der
Bild-Transcoder, der denselben `/:/`-Aufbau hat und aus dem die Plakate
kommen, und die Mediathek selbst. Wenn die antworten und der
Video-Transcoder nicht, liegt es nicht an Flixys Adressen.
Und der Probe nimmt jetzt `--channel 002`: bisher hat er immer Sender 001
genommen, auf dem gerade nichts läuft — ein Sender ohne Sendung sagt über
das Einschalten wenig aus. Ohne Angabe nimmt er den ersten, auf dem
etwas läuft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Gegenprobe ist eindeutig:
Gegenprobe — Transcoder mit: Mogli: Legende des Dschungels
→ HTTP 400
Eine gewöhnliche Datei scheitert genauso. Damit ist die Suche der letzten
Tage an der falschen Stelle gelaufen: Transcoding hat in Flixy noch nie
funktioniert, es ist nur nie aufgefallen. Filme laufen über DirectPlay,
da wird der Transcoder gar nicht gefragt — Live-TV ist das Erste, was ihn
zwingend braucht.
Diese Annahme habe ich tagelang mitgeschleppt, ohne sie zu prüfen. Sie zu
prüfen hat zehn Zeilen gekostet.
Jetzt wird richtig halbiert, an einer Datei statt an einem Sender: von
„nur Pfad und Token" aufwärts, Angabe für Angabe, bis eine davon die 400
auslöst. Dazu derselbe Satz an den Entscheider, der in Plex' Format
antwortet statt mit HTML.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Abwarten brachte nichts: der Vorgang meldet auch nach zwölf Sekunden
keine Daten. Und jede Anfrage an den Transcoder endet mit einer nackten
400 — auch die an den Entscheider, der sich sonst erklärt.
Das ist ein Muster, das nicht nach Live-TV aussieht, sondern nach dem
Transcoder selbst. Dass er funktioniert, habe ich die ganze Zeit
vorausgesetzt und nie geprüft: Filme laufen über DirectPlay, da wird er
gar nicht gefragt. Live-TV ist das Erste, was ihn zwingend braucht.
Also die Gegenprobe, vor allem weiteren Suchen: eine gewöhnliche Datei
aus der Mediathek durch den Transcoder. Läuft sie durch, liegt es an
Live-TV. Läuft sie nicht durch, habe ich tagelang am falschen Ende
gesucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Transcoder antwortet auf jede Form der Adresse mit einer nackten
„400 Bad Request"-Seite — ohne Plex-Meldung, ohne Hinweis. Der Entscheider
bekommt dieselben Angaben und gibt eine Plex-Antwort zurück. Das ist die
letzte Stelle, an der dieser Server noch erklärt, woran es liegt.
Schlägt das Einschalten fehl, zeigt der Probe deshalb jetzt zusätzlich
die Antwort des Entscheiders — in beiden Kodierformen — sowie den
Empfänger, das Gerät und /livetv/sessions im Wortlaut.
Dazu kann der Probe beliebige Adressen abfragen:
`swift run FlixyProbe /livetv/dvrs/2`. Eine Schnittstelle ohne
Beschreibung erkundet man, indem man sie fragt.
Der Token wird aus jeder Ausgabe entfernt, falls der Server ihn
zurückspiegelt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Upload-Kontingent des Tages ist aufgebraucht — verbraucht von meinen
eigenen Vermutungen über eine Schnittstelle, die keine Oberfläche braucht.
Jede Runde ging als TestFlight-Build hinaus und kam als Screenshot zurück.
`swift run FlixyProbe` macht dasselbe in Sekunden: anmelden, Server
suchen, Senderliste und Programm lesen, das Einschalten durchprobieren —
mit derselben Logik wie die App. Der Token kommt über die übliche
Anmeldung und liegt im Schlüsselbund dieses Rechners; gedruckt werden
Pfade, Kennungen und Antworten, keine vollständigen Adressen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ScarriffleandClaude Opus 5