ScarriffleandClaude Opus 5
fb418c842d
Bis hierher konnte man sich bei Jellyfin anmelden und stöbern, aber nichts abspielen. Der Player war die letzte große Stelle, die Plex unmittelbar kannte. Drei Mitglieder kommen dafür in den Vertrag: eine Wiedergabe vorbereiten, sie beenden, den Fortschritt melden. Die Entscheidung **ob** umgerechnet wird, fällt weiterhin vorher im `PlaybackDecider` — der Server führt sie nur aus. Genau diese Trennung fehlte: der Player hat Plex' Transcoder angesprochen und konnte deshalb mit nichts anderem reden. `MediaBackendError` bekommt einen siebten Fall: `refused(reason:)`. Der Server hat verstanden und sagt nein, in eigenen Worten. Bei Plex war genau dieser Satz die einzige brauchbare Spur, und er ging tagelang verloren, weil es dafür keinen Fall gab. Bei Jellyfin kommt die Adresse einer umgerechneten Fassung vom Server selbst (`PlaybackInfo` → `TranscodingUrl`), nicht von uns. Er weiß, welche Spuren er kopieren kann und welche er neu rechnen muss. Drei Dinge, die beim Hinsehen auffielen: - **`startTimeTicks` gehört nicht in die Anfrage.** Sonst entscheiden zwei Stellen über den Startpunkt: der Server ließe den Strom dort beginnen, und der Player spränge noch einmal um dieselbe Strecke vor. Bei einundzwanzig Minuten Fortschritt landet man bei zweiundvierzig. - **Der erste Bericht braucht einen eigenen Endpunkt.** Ohne ihn erscheint der Titel bei Jellyfin nirgends als „läuft gerade". Er fiel zunächst aus, weil er die Laufzeit verlangte — und die steht erst Sekunden nach dem Öffnen fest. Jetzt tut es für die erste Meldung die des Servers. - **In der Download-Adresse standen Titel und Fassung vertauscht.** Bei einem Film mit einer Fassung sind beide Kennungen dieselbe und nichts fällt auf; bei zweien schon. `MediaFile` sagt jetzt, zu welchem Titel sie gehört. Live-TV bleibt bei Plex und wird als Einziges noch unmittelbar durchgereicht. Ein Tuner ist ein Stück Hardware, und die fünfhundert Zeilen, die es gekostet hat, ihn zu bändigen, gehören in keinen gemeinsamen Vertrag. Nachgesehen, nicht nur gebaut: gegen die Attrappe läuft ein echtes Video, der Beginn wird gemeldet, der Fortschritt kommt in Ticks mit Sitzung und Fassung an. Was die Attrappe **nicht** beantworten kann, ist, ob ein echter Jellyfin das Geräteprofil annimmt und eine Umrechnung anbietet — das entscheidet erst ein richtiger Server. 257 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.4 KiB
Jellyfin-Attrappe
Ein Server, der so tut, als wäre er Jellyfin — gerade so viel, dass die App sich anmelden und stöbern kann. Gedacht fürs Ansehen der Oberfläche, nicht fürs Prüfen der Protokollschicht; dafür gibt es Tests mit aufgezeichneten Antworten.
python3 Tools/JellyfinStub/server.py
Dann in der App Mit Jellyfin anmelden → 127.0.0.1 eintragen. Quick
Connect bestätigt sich nach drei Abfragen von selbst, damit der Bildschirm mit
dem Code sichtbar wird und die Anmeldung trotzdem durchläuft.
Die Bilder sind einfarbige Flächen, deren Farbe aus der Kennung des Titels entsteht. Das ist Absicht: so lässt sich auf einen Blick erkennen, ob der Aufmacher tatsächlich weiterwandert und ob eine Kachel das Bild zeigt, das zu ihr gehört.
Abgespielt wird sample.mp4 — zehn Sekunden Farbverlauf, mit einem kleinen
Swift-Programm erzeugt. Der Server beantwortet Bereichsanfragen, weil der
Systemplayer eine Datei nie am Stück holt.
Was hereinkommt, steht unter http://127.0.0.1:8096/__reports: jede
Wiedergabemeldung mit ihrem Anfragekörper. Damit lässt sich prüfen, ob die App
den Beginn meldet, ob der Fortschritt in Ticks ankommt und ob am Ende
abgeräumt wird.
Mit --unanalysed melden die Quellen keine Spuren. Dann entscheidet die App
wie bei einem Server, der eine Datei noch nicht untersucht hat.
Kein echter Server wird dabei angefasst, und es gehen keine Zugangsdaten über die Leitung.