DogFatherGitandClaude Opus 5
25cf6a0163
GEFUNDEN HAT ES DAS PROTOKOLL, das eine halbe Stunde vorher dazukam. Filipes Versuche standen Minuten spaeter als `video_gescheitert` da, mit Grund: highlight .../@dogfather0804/photo/7693113561568136470 -- 400 highlight https://vm.tiktok.com/ZN8kdxP9N/ -- 400 Am echten Konto nachgemessen: .../photo/7693113561568136470 -> 400 "Something went wrong" .../video/7693113561568136470 -> 200, mit Titel vm.tiktok.com/ZN8kdxP9N/ -> leitet auf die /photo/-Adresse TikToks Auskunft kennt FOTOPOSTS (Slideshows) nicht -- dieselbe Nummer unter /video/ aber schon. Filipe postet seit kurzem solche Beitraege. Deshalb "es ging doch immer bis jetzt": Es lag weder an einer Auslieferung noch am Haus, sondern an der Art des Posts. Der Server war die ganze Zeit unveraendert (ein Neustart seit 04.10.), und genau das hat die Suche in die falsche Richtung geschickt. Jetzt wird bei einem Fehlschlag ein zweites Mal gefragt: erst den Kurzlink aufloesen -- er verraet von aussen nicht, was dahinter steckt --, dann /photo/ auf /video/ drehen. Aufgeloest wird nur ueber den Ort-Kopf (`redirect: "manual"`), die Seite selbst wird nie geholt; sie ist ein Megabyte gross und enthaelt nichts, was wir brauchen. NUR BEIM FEHLSCHLAG: Ein gewoehnliches Video kostet keine einzige zusaetzliche Anfrage. Gemessen: Video 204 ms wie bisher, Fotopost 676 ms, Kurzlink auf Fotopost 827 ms -- alle drei mit Titel und Vorschaubild. Gegengemessen an genau den zwei Adressen, die bei ihm gescheitert sind: beide liefern jetzt Titel und Bild. pruef-video 74, pruef-teilen 27 -- 0 Fehler. WAS ICH DARAUS MITNEHME: Ich habe heute stundenlang von aussen ausgeschlossen, was es NICHT ist -- Adresse, Haus, Sitzung, Manifest, Service Worker, Zwischenspeicher. Beantwortet hat die Frage am Ende eine einzige Protokollzeile. Die haette am Anfang stehen muessen, nicht nach der halben Suche. Dieselbe Lehre wie am 06.09. im Shop, und ich habe sie heute zweimal gebraucht. Co-Authored-By: Claude Opus 5 <[email protected]>
