Flimmer

1. Ziele und Grundentscheidungen

• Werbefrei durch eigenes Abspielen. Flimmer bettet keine YouTube-Seite ein. Es fragt YouTubes interne Schnittstelle (InnerTube) über YouTube.js ab und spielt den Videostrom selbst ab. Werbung wird nie geladen.
• Eine Codebasis für macOS, Windows, Linux, Android und später iOS: Tauri 2 (Rust) mit einer Svelte-5/SvelteKit-Oberfläche in TypeScript, gebaut mit Deno und Vite. SwiftUI wurde verworfen, weil es nur Apple-Systeme abdeckt.
• Nur freizügige Lizenzen (MIT, Apache, MPL, ISC). Kein GPL-Code: kein NewPipe Extractor, kein FreeTube-Code (AGPL, auch nicht abschreiben). Kein „YouTube“ in Name und Symbol.
• Keine Konten, kein eigener Server. Abos, Playlists, Verlauf und Einstellungen liegen im lokalen Speicher der WebView.
• Originalton als Standard, Originaltitel statt YouTubes automatischer Übersetzung.
• Oberfläche, Kommentare im Code, Doku und Commits sind deutsch.
• Verteilt wird über GitHub (Kapitel 13), nicht über App Stores:
  • Werbefreies YouTube verstößt gegen YouTubes Nutzungsbedingungen. Apple verlangt in den Regeln 5.2.2 und 5.2.3 die Erlaubnis des Dienstes und entfernt solche Apps auf Beschwerde (Fall *Musi*, 2024; Musis Klage gegen Apple im März 2026 abgewiesen). Eine Store-Fassung würde nicht bestehen.
  • Im Mac App Store wäre außerdem der eigene Updater verboten.
  • Weitergabe ohne Warnmeldung braucht ein Apple-Entwicklerkonto (99 €/Jahr) für Signatur und Notarisierung; Windows zeigt unsignierten Programmen eine SmartScreen-Warnung.

2. Schnellstart

Voraussetzungen: Deno 2, Rust (rustup), auf dem Mac die Xcode Command Line Tools, unter Linux WebKitGTK und GStreamer (siehe .github/workflows/build.yml).

deno install

. "$HOME/.cargo/env" && deno task tauri dev

tauri dev startet Vite (deno task dev, Port 1420) und die Debug-App. Der Rust-Bauordner ist src-tauri/target.noindex (über src-tauri/.cargo/config.toml), damit Spotlight das Bauergebnis nicht als zweite App anbietet.

Nur im Browser

Die Oberfläche läuft auch in Chromium. Weil der Browser YouTube nicht direkt abfragen darf (CORS), leitet ein kleiner Proxy die Anfragen weiter:

deno task devproxy

deno task dev

Dann http://localhost:1420 öffnen. Chromium verhält sich wie der Windows-Weg (shaka-player, DASH).

Umgebungsvariablen der App

Beispiel ohne Klicken (Vite muss laufen):

FLIMMER_OPEN='/watch?v=_2i-dhRl9wo&t=70' src-tauri/target.noindex/debug/flimmer

Die Zeilen [ui:…] (log() aus src/lib/log.ts) und [media] (Medien-Proxy) im Terminal zeigen, was passiert. Debug-App und installierte App haben getrennte Speicher (~/Library/WebKit/flimmer bzw. ~/Library/WebKit/io.github.mhd6271.flimmer).

Mac-App lokal bauen

deno task tauri build

Ergebnis: src-tauri/target.noindex/release/bundle/macos/Flimmer.app (dazu ein .dmg). Windows- und Linux-Pakete baut GitHub Actions (*Actions → Bauen* von Hand starten oder ein Tag v… pushen); die Dateien hängen als Artefakte am Lauf.

Aufgaben

3. Verzeichnisse

4. Architektur und Datenfluss

 Oberfläche (Svelte, WebView)
   │  YouTube.js ──proxyFetch──► Tauri-HTTP-Plugin (Rust) ──► youtube.com / youtubei.googleapis.com
   │  SponsorBlock / DeArrow ──fetch──► sponsor.ajay.app (CORS erlaubt)
   │
   │  <video> ◄── HLS direkt (Mac/iOS: WebKit spielt googlevideo selbst)
   │  <video> ◄── MSE ◄── shaka-player ◄── media://?u=… ──► media.rs ──► *.googlevideo.com
   │
   └─ Chromecast:  cast.svelte.ts ─invoke─► lan.rs (HTTP im WLAN) + cast.rs (CASTV2/TLS) ──► Fernseher
                   (nur SABR: cast-sabr.ts lädt die Stücke selbst und legt sie per cast_live_put in lan.rs ab)

1. Netz: net.ts stellt proxyFetch bereit. In der App läuft jede YouTube-Anfrage über das Tauri-HTTP-Plugin (Rust, ohne CORS, eigener User-Agent), im Browser über tools/devproxy.ts. YouTube.js bekommt proxyFetch als fetch.
2. Daten: yt.ts kapselt YouTube.js und liefert eigene, schlanke Typen (VideoItem, VideoDetails, StreamInfo …). Seiten sprechen nur mit yt.ts, nie direkt mit YouTube.js.
3. Wiedergabe: Die Video-Seite lädt Details und Stream und füllt den globalen Zustand playback. Der Player im Layout wählt eine Abspieltechnik und hängt sie an das eine <video>.
4. Medien: Auf Apple-WebKit lädt <video> die HLS-Listen und -Stücke direkt von googlevideo (WebKit braucht dafür kein CORS). Überall sonst holt shaka-player die Daten per fetch über media://; media.rs lädt sie in Rust und gibt sie mit CORS-Kopfzeilen zurück.
5. Zustand liegt in Svelte-5-Runen-Modulen (*.svelte.ts), gespeichert über persist.svelte.ts im localStorage der WebView.

5. YouTube-Zugriff

src/lib/yt.ts (~870 Zeilen). YouTube.js wird einmal erzeugt (youtube()), mit proxyFetch und einem JavaScript-Ausführer für die Entschlüsselung der Adressen (sandbox.ts, Web Worker mit Zeitlimit; YouTube.js hat ab Version 14 keinen eingebauten Interpreter mehr).

Clients

Warum VISIONOS? Gemessen am 13.10.2026 (deno task probe): Er liefert eine HLS-Adresse und Format-Adressen ohne Prüf-Token. WEB liefert nur noch SABR; IOS, MWEB und ANDROID_VR brechen ohne Token nach etwa 1 MB ab; TV ist gesperrt.

Live: VISIONOS liefert für Live nur HLS bis 720p aus MPEG-TS-Stücken mit eigener Tonspur (AAC mit ID3-Kopf). Der Mac-Systemplayer spielt das; shaka kann es nicht umwandeln (Fehler 3018). Für shaka holt Flimmer deshalb YouTubes eigenes DASH-Manifest über ANDROID_VR (fMP4-Stücke bis 1080p, ohne Prüf-Token ladbar; gemessen 13.10.: 15 Stücke, 12 MB, alle HTTP 200). SABR geht für Live nicht, und Live wird nicht im Verlauf fortgesetzt.

Der Weg zum Stream

stream.ts → loadStream(id, forceSabr):

• Einstellung player.stream = auto: erst getStream (VISIONOS), bei Fehler getSabrStream.
• visionos oder sabr erzwingen jeweils einen Weg.

getStream gibt StreamInfo zurück:

PlaybackError trägt YouTubes Begründung („Melde dich an …“, „Video privat“).

KI-Kennzeichnung

YouTube legt sie in /next als Abschnitt howThisWasMadeSectionViewModel („Wie wurde dieser Inhalt erstellt?“) in der Beschreibung ab; YouTube.js parst ihn als HowThisWasMadeSectionView. Derselbe Abschnitt steht auch bei automatischer Synchronisation. Unterschieden wird sprachunabhängig am verlinkten Hilfeartikel: answer/15447836 = mit KI erstellt/verändert, answer/15569972 = Synchronisation (aiLabelFrom → VideoDetails.aiLabel). Gefunden mit tools/probe-ai-label.ts; dort zeigte sich auch, wie lückenhaft die Selbstauskunft ist (offensichtliche „AI-Generated“-Trailer ohne Kennzeichnung).

Anfragen sparen (18.10.2026): getDetails holt nur noch /next und teilt sich die /player-Antwort (VISIONOS) mit getStream (visionosPlayer, 60 s gemerkt) – vorher stellte YouTube.js' getInfo eine zweite /player-Anfrage (WEB), ein Drittel aller Anfragen je Video. Während einer Sperre gibt es dann keine zusätzliche Anfrage; es fehlen höchstens Dauer und Originaltitel. Ebenso: Originaltitel nur für sichtbare Karten (siehe Externe Dienste), Live-Chat pausiert bei verborgenem Fenster, Abo-Feed stündlich und nicht während einer Sperre.

Bestandsaufnahme der Anfragen (24.10.2026, nach einer Sperre an einem Testtag): Je geöffnetem Video gehen an YouTube /player (VISIONOS, geteilt), /next (Details) und – nur auf Tippen, seit 0.5.29 (ui.commentsAuto lädt wie früher von selbst; die Anzahl kommt aus /next) – ein weiteres /next für die Kommentare; dazu oEmbed für jede neue Karte in der Liste „ähnliche Videos“ (≈ 20, gemerkt) und beim Weiterspielen dasselbe für das nächste Video. Scheitert VISIONOS: bis zu zwei weitere /player (WEB, MWEB) plus BotGuard (zwei Aufrufe an googleapis) und die laufenden SABR-Anfragen an googlevideo. Der Abo-Feed stellt je Kanal eine /browse-Anfrage, der Fernseher beim Verweilen auf einer Karte eine /player-Anfrage (Vorladen). Darauf gedrosselt: Vorladen erst nach 3 s Ruhe und höchstens eins je 15 s (stream.ts); onVisible (actions.ts) feuert erst, wenn ein Element 700 ms in Sicht bleibt – schnelles Scrollen löst keine oEmbed-, DeArrow- oder Kommentar-Anfragen aus; oEmbed eine Anfrage nach der anderen mit 400 ms Abstand; Abo-Feed ein Kanal nach dem anderen mit 750 ms Pause. net.ts zählt die Anfragen je Art, das Layout schreibt alle 10 Minuten „YouTube-Anfragen: n (player …, next …, browse …)“ ins Protokoll. Beim Testen gilt: keine curl-Abrufe von /watch-Seiten und keine Probe-Skripte mit eigenem Innertube.create gegen YouTube vom selben Anschluss – jede davon zählt wie ein neuer Client; am 24.10. kam die Sperre nach Emulator-Läufen, Probe-Skripten und etwa einem Dutzend Teststarts binnen zwei Stunden (nur IPv6 betroffen, IPv4 blieb frei).

getDetails merkt Ergebnisse 5 Minuten (höchstens 50): Das Weiterspielen prüft das nächste Video vorab (pickAutoplay in playback.svelte.ts, Einstellung player.skipAi), die Video-Seite braucht dieselben Daten gleich danach.

Weitere Funktionen

search (mit Filter Videos/Kanäle/Playlists, Fortsetzung über Page.next), getDetails (WEB, inkl. liveChat, ähnliche Videos, Originaltitel), getChannel/getChannelVideos/getChannelPlaylists, resolveChannel (@Name, /c/…, /user/…), getLatestVideos (Abo-Feed über den Videos-Tab mit params: EgZ2aWRlb3PyBgQKAjoA, weil YouTubes RSS-Feeds 404 liefern), getPlaylist, getComments, parseVideoId/parsePlaylistId/parseStartTime (Links), parseRelativeDate.

6. Wiedergabe: Wege und Abspieltechniken

Jede Technik implementiert Engine aus player/engine.ts:

interface Engine {
  kind: 'hls' | 'shaka' | 'progressive' | 'sabr';
  onfail?: (reason: string) => void;
  attach(video, stream, quality, audio?): Promise<void>;
  setAudio(track): Promise<void>;
  qualities(): QualityOption[];
  setQuality(choice): Promise<void>;
  destroy(): Promise<void> | void;
}

Auswahl im Player

Player.svelte baut je Stream eine Kandidatenliste und probiert sie der Reihe nach (start). Meldet eine Technik onfail, kommt die nächste:

1. SABR-Stream → nur SabrEngine.
2. player.engine = native → NativeHlsEngine; shaka → ShakaEngine.
3. auto auf Apple-WebKit → NativeHlsEngine, dann ShakaEngine.
4. auto sonst → ShakaEngine.
5. Danach ProgressiveEngine, zuletzt NativeHlsEngine, falls noch nicht dabei.

Scheitert eine Technik erst beim Abspielen (Fehler am <video>), kommen zuerst die übrigen Kandidaten dran (runCandidates, fallbacks), seit 0.5.16; vorher ging es dann sofort zu SABR. Der Systemplayer versucht vorher selbst die Original-Liste statt der aufbereiteten (recoverFromError). shaka gibt nach drei HTTP-403-Antworten auf (shaka meldet sie nur als behebbar und versuchte es endlos). Scheitert am Ende auch SABR, zeigt der Player „YouTube gibt dieses Video gerade nicht an Flimmer heraus“ mit „Auf YouTube öffnen“ (BLOCKED). Anlass (18.10.2026): ein heute-show-Video, bei dem YouTube über HLS keinen Ton lieferte (alle Tonspuren 404, nur VP9-Bild), DASH mit 403 und SABR mit leeren Antworten – vermutlich nur mit gültigem Prüf-Token.

Scheitern alle Kandidaten des VISIONOS-Wegs, lädt die Video-Seite den SABR-Stream (onfailure → loadStream(id, true)); im Mini-Player ohne Video-Seite übernimmt das fallbackInMini.

Fehlerbehandlung

• shaka: lädt DASH zuerst, HLS nur, wenn es kein DASH gibt (seit 0.5.13). YouTubes HLS-Ton ist AAC in MPEG-TS, das shaka nicht umwandeln kann: Meist scheitert HLS sofort (3015), manche Videos luden aber ohne Ton (Chromium hielt sie im Hintergrund als „video-only“ an), ohne Bild kam 3018 erst beim Abspielen. Netzfehler 1002/1003 werden bis zu 5× wiederholt (retryPending mit Entprellung), statt sofort auf SABR zu wechseln.
• SABR: Netzfehler bei laufender Wiedergabe sind normal (googlevideo bricht Verbindungen ab). Neu versucht wird nur, wenn die Wiedergabe steht (readyState < HAVE_FUTURE_DATA, nicht pausiert, nicht zu Ende): die ersten drei Male nach 3 s, danach mit wachsendem Abstand bis 30 s, und ohne Obergrenze – läuft das Video wieder (timeupdate > 2 s weiter), beginnt die Zählung von vorn. Bis 0.5.12 war nach 5 Versuchen Schluss, der Zähler wurde nur bei einem Qualitätswechsel zurückgesetzt: Auf dem Pixel 6a mit gesperrtem Bildschirm (über 100 Netzfehler in 3 Minuten) war danach Stille. Fehler werden höchstens alle 10 s protokolliert, mit Adresse und Ursache. Andere kritische Fehler → onfail.
• SABR-Bremse (sabr-adapter.ts, brake): shaka fragt nach jeder leeren Antwort sofort wieder an – gemessen am Google TV 2–3 Anfragen pro Sekunde, endlos, auch im Mini-Player (fehlendes Prüf-Token, YouTube liefert nach einer Schonfrist mit Schutzstatus 2 nichts mehr). Das sieht für YouTube nach einem Bot aus. Gezählt wird an den gepufferten Sekunden über alle Bereiche (kleine Antworten ohne Bild/Ton gibt es zwischendurch immer): ab der achten Anfrage ohne Änderung wird vor jeder gewartet (1, 2, 4 … 30 s), nach 22 aufgegeben (BAD_HTTP_STATUS → onfail, gut 5 Minuten). Nicht das Ende des letzten Bereichs nehmen: Nach einem Sprung zurück füllt shaka einen neuen Bereich davor, das letzte Ende bliebe stehen – 0.5.18 brach so eine laufende Wiedergabe ab. Nach dem Aufgeben baut Player.svelte (onfail) jeden Abspieler ab (seit 22.10.2026 auch shaka: ein aufgebender shaka-Abspieler wiederholte HTTP-403-Abrufe mit ~12/s, solange die Seite keinen neuen Strom lud), bei SABR und zeigt „YouTube gibt dieses Video gerade nicht heraus“; die Bremse wartet danach 30 s, bevor sie erneut wirft. Ohne beides lief der Abspieler weiter und die Bibliothek wiederholte die leeren Anfragen ohne Pause – TCL 21.10.2026 unter YouTubes Anschluss-Sperre (LOGIN_REQUIRED für alle Clients, auch vom Mac): ~60 Versuche/s, 3500 in einer Minute, nichts davon ging ins Netz (die Bremse wirft vor dem Senden), die Rechenlast blieb. Mit dem Fix: nach „gibt auf“ keine Zeile mehr, 0 % CPU.
• Kinder-Inhalte („für Kinder“ markiert, z. B. „Reportage für Kinder“): VISIONOS und WEB melden „nicht verfügbar“, nur MWEB liefert (SABR). MWEB gibt Untertitel-Adressen relativ an (/api/timedtext…); YouTube.js baut im SABR-Manifest new URL(base_url) → „Invalid URL“, SABR ging so nie. absoluteCaptionUrls in yt.ts ergänzt den Host. Ist VISIONOS für das Video gerade erst gescheitert, fragt SABR es nicht noch einmal (eine Anfrage weniger).
• Nach SABR: Beim Aufräumen meldet sabr-adapter.ts shakas HttpFetchPlugin wieder für http/https an. Sonst spielte danach kein shaka-Video mehr in der Sitzung (Fund aus dem Code-Review vom 18.10.).

7. Der durchgehende Player

Video und Bild-in-Bild sollen einen Seitenwechsel überstehen. Darum liegt der Player im Layout (+layout.svelte), nicht auf der Video-Seite:

• playback.svelte.ts hält den Zustand (playback.props: Stream, Abschnitte, Startzeit, Titel, Rückrufe, ähnliche Videos) und den Platz.
• Die Video-Seite meldet mit use:playerSlot einen Platz an. Das Layout verschiebt das <video> per appendChild dorthin; ohne Platz in die Mini-Ablage unten rechts. Nie neu anlegen: Ein Medienelement, das das Dokument verlässt, hält an und beendet Bild-in-Bild. Verschoben wird vor dem Seitenabbau (beforeNavigate).
• Ein <video> für alle Videos (seit 0.5.6, kein {#key}): So bleiben AirPlay und Bild-in-Bild beim nächsten Video erhalten. Folgen, die beachtet werden müssen:
  • start() setzt allen Zustand des vorigen Videos zurück (Qualität, Hinweise, Stummschaltung durch Abschnitte, Untertitelspuren, Cast-Menü).
  • onTimeUpdate, onEnded und onPause prüfen startedWith?.s === stream. Sonst landet die alte Stelle im Verlauf des neuen Videos.
  • restorePosition gibt ein Abbrechen zurück; ein offener Sprung darf nicht das nächste Video treffen.
• Werte über das Layout erzeugen bei jeder Änderung ein neues Props-Objekt. Der Player vergleicht deshalb Element und Stream (startedWith) und startet nur bei echtem Wechsel neu. Den Stream hält die Seite als $state.raw: ein $state-Proxy wäre ein anderes Objekt und startete das Video neu.
• Weiterspielen im Mini-Player: playNextInMini lädt das nächste ähnliche Video ohne Video-Seite.
• Mini-Player ziehen: setPointerCapture an der Leiste (Fenster-Listener blieben in der Mac-App hängen). Ein Klick ohne Bewegung führt zur Video-Seite zurück (dragEnd). Die Lage steht in ui.miniRight/miniBottom. Auf dem Handy ist er schmaler (min(260px, 62vw)) und rastet nach dem Loslassen unten links oder rechts ein (dragging), frei in der Mitte verdeckte er die Listen.

8. Tonspur, Qualität, Untertitel, SponsorBlock

Tonspur (audio.ts, hls.ts, native.ts)

• chooseAudio(tracks, settings) wählt nach player.audio (original | dubbed | dubbed-human) und audioLanguage. Original = Rolle main bzw. Name mit „original“.
• HLS: YouTube markiert in der Hauptliste alle Spuren mit DEFAULT=NO, AUTOSELECT=YES. Das System nimmt dann die Synchronisation in der Systemsprache (oft „Deutsch (KI)“). originalAudioId(master) findet die Spur mit „- original“ im Namen. buildMaster(…, { audioId }) setzt nur die gewünschte Spur auf DEFAULT=YES.
• macOS übergeht DEFAULT=YES trotzdem manchmal. Deshalb schaltet enforceAudio() nach loadedmetadata und addtrack die WebKit-audioTracks selbst um (seit 0.5.7).
• shaka/DASH: Original = Rolle main, Synchronisation = dub; selectAudioTrack und audioPreferences in shaka.ts.
• audio_track.id (z. B. de.3) entspricht YT-EXT-AUDIO-CONTENT-ID in der HLS-Liste.

Qualität

• player.quality = auto oder Höchstauflösung. HLS: capMaster entfernt höhere Varianten. shaka/SABR: applyQuality (shaka.ts); selectMaxHeight(player, maxHeight) wählt nur unter den Varianten mit der aktiven Tonspur, sonst springt die Tonspur beim Qualitätswechsel zurück.
• Auf dem Fernseher gilt eingebettet höchstens 1080p (TV_EMBEDDED_MAX, siehe Android/Google TV).
• Auf dem Handy begrenzt „Automatisch“ auf 1080p (MOBILE_AUTO_MAX, abr.restrictions.maxHeight): SABR kletterte auf dem Pixel 6a auf 4K und blieb stecken.
• Android im Hintergrund wechselt die Qualität nicht (freezeQuality): Chromium bringt bei unsichtbarem Bild einen Spurwechsel nicht in Gang – ein Versuch, im Hintergrund auf 240p herunterzuschalten, blieb genau beim ersten kleineren Stück stehen (und lief beim Entsperren weiter).
• Der Player zeigt die tatsächlich gespielte Auflösung („gerade 1080p“, onResize).

Untertitel

• Spuren aus captions, geladen als VTT über media:// (Mac: direkt), zwischengespeichert als Blob (vttCache, beim Videowechsel freigegeben).
• cleanAutoVtt räumt Spracherkennungs-Untertitel auf (doppelte, rollende Zeilen).
• YouTubes Übersetzung (tlang) liefert HTTP 429 und ist nicht eingebaut.

SponsorBlock (sponsorblock.ts)

• fetchSegments(id) fragt sponsor.ajay.app/api/skipSegments/<Hash-Präfix> mit den ersten 4 Zeichen von SHA-256(ID) (sha256.ts) und filtert lokal.
• CATEGORIES legt Bezeichnung, Farbe, Standard und erlaubte Wirkungen je Kategorie fest (skip, manual, show, off). actionType mute schaltet stumm statt zu springen.
• Der Player prüft in onTimeUpdate, ob die Stelle in einem Abschnitt liegt. „Rückgängig“ merkt den Abschnitt für dieses Video. countSkip meldet übersprungene Abschnitte (nur die UUID), wenn countSkips an ist.
• Keine eigenen Kopfzeilen an sponsor.ajay.app senden: Die CORS-Vorabprüfung scheitert sonst (fiel bei DeArrow auf).

9. Rust: Medien-Proxy, WLAN-Server, Chromecast

lib.rs

Befehle für die Oberfläche: log (schreibt [ui:level] ins Terminal), startup_options (FLIMMER_OPEN, FLIMMER_SETTINGS, FLIMMER_CAST), open_text_file/save_text_file (Abo-Import und -Export über den Dateidialog), cast_devices/cast_start/cast_status/cast_control, cast_serve/cast_unserve, das Stücklager cast_live_*, set_webview_ua. Registriert das Schema media und die Plugins (http, opener, Updater und process nur auf dem Desktop). Das Hauptfenster legt setup selbst an (WebviewWindowBuilder::from_config, in tauri.conf.json create: false), weil nur so ein Startskript für alle Frames mitgegeben werden kann (initialization_script_for_all_frames) – siehe den nächsten Abschnitt.

src/botguard/frame.ts – Prüf-Token im youtube.com-Frame

Googles BotGuard prüft die Adresse der Seite, auf der es läuft: Mit https://www.youtube.com/ gibt GenerateIT ein Integritäts-Token zurück, mit der App-Adresse (tauri://localhost, http://tauri.localhost) nur das unbrauchbare Ersatz-Token und keine Signal-Funktion (in Deno + jsdom nachgestellt, 24.10.2026 – ein verpacktes window/document/location im Hauptfenster half nicht, die VM kommt an das echte Fenster). Deshalb legt src/lib/sabr/botguard.ts beim ersten SABR-Video einen versteckten <iframe> auf https://www.youtube.com/robots.txt?flimmer-botguard=1 an (winzig, Text, ohne Skripte, ohne X-Frame-Options, ohne CSP). Tauris Startskript frame.ts läuft in jedem Frame, tut aber nur dort etwas: Create → Interpreter laden → BotGuardClient.snapshot → GenerateIT → WebPoMinter, Anfragen an jnn-pa.googleapis.com direkt (CORS erlaubt youtube.com), Token-Wünsche und Antworten über postMessage (`{ flimmer: 'flimmer-botguard', type: 'mint' | 'token'

deno bundle gebaut (deno task botguard, Teil von deno task build) und per include_str! eingebunden – nach Änderungen an frame.ts neu bauen und die frame.js mitcommitten. Ohne Tauri (Vite im Browser) gibt es kein Startskript, dann bleibt es beim vorläufigen Token. Mac-App: „BotGuard: bereit nach ~250 ms (1 Signale)“.

Offen (24.10.2026): Trotz echtem Token nahm der Datenstrom-Server die SABR-Anfragen nach wenigen Läufen nicht mehr an (Schutzstatus 2, dann Antworten ohne Material; der erste Lauf spielte über 45 s). Versuch mit dem User-Agent des WebViews für die SABR-Abrufe (set_webview_ua, mediaUrl(url, { webviewUa: true }), withUserAgent fürs HTTP-Plugin) brachte mit dem nackten WKWebView-UA nur noch leere 200er – vorerst aus (webviewUa: false). sabr-adapter.ts protokolliert bei leeren Antworten jetzt Status, Schutzstatus, Fehler, Umleitung, Kontext-Update (describeEmpty). Nicht in kurzer Folge testen: Jeder abgebrochene SABR-Lauf scheint den Anschluss weiter einzuschränken.

media.rs – Medien-Proxy

• Schema media://localhost/?u=<Adresse> (Windows/Android: http://media.localhost/).
• Erlaubt nur googlevideo.com und YouTubes Untertitel-Schnittstelle (allowed). Reicht range, content-type, accept, x-goog-visitor-id weiter und gibt content-range, accept-ranges, x-head-seqnum, x-walltime-ms zurück, mit CORS-Kopfzeilen. POST für SABR wird durchgereicht.
• IP-Bindung: googlevideo-Adressen gelten nur für die IP (und IP-Version), die sie angefordert hat (Parameter ip=). client_for wählt einen reqwest-Client, der an die passende lokale Adresse gebunden ist.
• Android verliert Kopfzeilen eigener Protokolle: Range kommt dort als Parameter range=, offene Bereiche werden über clen= geschlossen.
• Bekannte Schwäche: Antworten werden ganz gepuffert (bei der 360p-Notlösung die ganze Datei).

lan.rs – Medienserver im WLAN

• Für Chromecast: Ein Fernseher hätte bei IPv6 eine andere IP und bekäme 403. Der Server lädt mit der IP des Rechners und reicht weiter.
• Startet erst mit cast_serve(master, dash) (axum, zufälliger Port, alle Schnittstellen). Jede Sitzung hat einen zufälligen 128-Bit-Pfad, sonst 404. rewrite_playlist schreibt HLS-Listen um, rewrite_mpd die <BaseURL> eines DASH-Manifests (& beachten) – Unterlisten und Stücke laufen so ebenfalls über den Server, Range wird durchgereicht.
• CORS auf jeder Antwort (with_cors, auch OPTIONS und Access-Control-Allow-Private-Network): Der Empfänger auf dem Fernseher ist eine Webseite auf www.gstatic.com. Vorher fehlten die Kopfzeilen bei den Listen – Chromium meldete ERR_FAILED, Cast LOAD_FAILED (am TCL 24.10.2026 gefunden).
• Protokoll je Abruf ([lan] Liste/Stück … → Status · kB · ms, im Android-Logcat unter RustStdoutStderr).
• Freigaben verfallen erst beim Stoppen (cast_unserve).
• Stücklager für SABR (seit 0.5.29): Gibt YouTube ein Video nur über den Ausweichweg heraus, gibt es keine Liste zum Weiterreichen – dann lädt das Gerät selbst (src/lib/cast-sabr.ts, serveSabrForLan: SabrStream aus googlevideo pumpen, Bild H.264 + Ton AAC, Bremse über einen fetch-Wrapper, höchstens 120 s Vorsprung vor dem Fernseher, dann Pause per abort() und start({ state })) und legt jedes Stück per cast_live_put ab (Rohdaten im Body, Kenndaten in Kopfzeilen x-token, x-track, x-init, x-seq, x-start-ms, x-duration-ms; live_put ist der Kern ohne Tauri). cast_live_open(duration_ms) legt das Lager an und gibt …/live.mpd zurück; build_live_mpd schreibt daraus ein dynamisches DASH-Manifest (availabilityStartTime 1970, also alles Gelistete verfügbar; suggestedPresentationDelay = ganze bisherige Spanne, damit der Empfänger vorn beginnt statt am „Live-Rand“; SegmentTimeline + $Number$ ab dem ersten vorhandenen Stück, nur die lückenlose Folge), das der Fernseher alle 2 s neu holt (minimumUpdatePeriod); cast_live_finish macht es statisch (Ende), cast_live_close räumt auf. prune_live wirft Stücke weg, die mehr als 90 s hinter der Stelle des Fernsehers liegen (cast::position_ms), und hält das Lager unter 160 MiB. Routen live.mpd, i/{track}, s/{track}/{seq}. Am TCL ohne YouTube belegt (Test live_tv, #[ignore]): ein ffmpeg-DASH-Ordner wird Stück für Stück abgelegt (erst drei voraus, dann eines je 4 s), der Empfänger begann bei 0,7 s, lief mit und spielte bis zum Ende (59 s) – CAST_MEDIA=/ordner CAST_DEVICE="Smart TV" cargo test live_tv -- --ignored --nocapture (Medien z. B. mit ffmpeg -f lavfi -i testsrc=… -f dash -seg_duration 4 -use_timeline 1 -use_template 1 -init_seg_name 'init-$RepresentationID$.m4s' -media_seg_name 'chunk-$RepresentationID$-$Number%05d$.m4s' out.mpd). Der TS-Teil mit echtem SABR war am 24.10.2026 noch nicht prüfbar (Sperre: YouTube lieferte auch für SABR keine Daten).
• AirPlay braucht ihn nicht: macOS reicht den Strom selbst an den Fernseher weiter. Ein früheres Umschalten auf den WLAN-Server erzeugte eine Endlosschleife und löste YouTubes Bot-Sperre aus (0.5.5).
• Was der Fernseher als Titel zeigt, kommt aus navigator.mediaSession.metadata (setzt Player.svelte mit Titel und Kanal im Original – basic_info.author statt „… und 2 weitere“ – und Vorschaubild). Der Titel läuft dabei durch displayTitle (format.ts, seit 0.5.12): ohne Hashtags, Emojis und Zusätze wie „(Official Video)“, weil der Fernseher lange Titel abschneidet. Dieselbe Kurzfassung bekommt die Android-Benachrichtigung. Ohne diese Angabe nahm macOS den Fenstertitel – YouTubes Übersetzung bzw. im Mini-Player noch den des vorigen Videos.

cast.rs – Chromecast

• Geräte über mDNS (_googlecast._tcp, mdns-sd), cast_devices(seconds).
• Eigene Umsetzung von CASTV2 statt rust_cast (das beantwortet PINGs beim Warten nicht): TLS mit rustls (Zertifikat wird nicht geprüft, Chromecasts haben selbst signierte), Nachrichten als Protobuf von Hand (encode_message/decode_message), höchstens 64 KiB je Nachricht.
• Verbindung per TLS zu Port 8009, Protobuf-Hülle mit JSON-Inhalt.
• Sitzung in eigenem Thread (run_session): Googles „Default Media Receiver“ (CC1AD845) starten, LOAD mit der WLAN-Adresse. Normale Videos als DASH (application/dash+xml, CastRequest.dash): castDash in cast.svelte.ts behält nur H.264-Bild (MP4) und eine AAC-Tonspur (MP4) – das spielt jeder Chromecast ohne Umwandeln. Live-Videos als HLS (nur H.264-Varianten, buildMaster({ codec: 'avc1' }), dazu hlsSegmentFormat: aac, hlsVideoSegmentFormat: mpeg2_ts). Warum nicht HLS für alles: YouTubes HLS mischt TS-Bild, nacktes AAC mit ID3 und VP9 als MP4; der Standard-Empfänger am TCL legte die Puffer an, hängte aber nie etwas an (schwarz, Ladekringel; 24.10.2026). Befehle über einen Kanal (Pause, Weiter, Springen, Stopp), Status für cast_status.
• Beim ersten Streamen fragt macOS eventuell, ob Flimmer eingehende Verbindungen annehmen darf.
• Oberfläche: cast.svelte.ts (findDevices, serveForLan mit Tonspur über audio?.id ?? originalAudioId, startCast, control, stopCast), Knopf und Fernbedienung im Player.
• Android (seit 0.5.28): derselbe Rust-Teil läuft im App-Prozess. Dazu: Erlaubnis ACCESS_LOCAL_NETWORK (Android 17, Laufzeit, Gruppe „Geräte in der Nähe“; MainActivity.castPermission, Ergebnis als Ereignis flimmer-localnet), MulticastLock während der Suche (multicast, sonst verwirft Android die mDNS-Antworten), beim Streamen meldet Player.svelte die Sitzung als „spielt“ an die Benachrichtigung (setSession(…, background: true)): Der Vordergrund-Dienst hält App, Medienserver und WLAN wach; Abspielen/Pause dort steuern den Fernseher, „Beenden“ hört auf. Auf dem Fernseher selbst gibt es keinen Knopf (isTV).
• Nächstes Video beim Streamen: Player.start gibt ein neues Video direkt an den Fernseher, wenn cast.active gesetzt ist (wartet bis 2,5 s auf den Titel), und lädt es hier erst bei „Zurück auf dieses Gerät“ (castHandoff/resumeHere mit resumeFrom). Ende am Fernseher (ended) ruft onended wie hier. In Rust lädt cast_start auf demselben Gerät per Command::Load im laufenden Empfänger nach – vorher beendete die alte Sitzung den Empfänger, den die neue gerade übernommen hatte („stopped“, Video fiel aufs Handy zurück). cast.svelte.ts zählt Sitzungen (session), damit späte Statusmeldungen der vorigen nichts beenden.
• Am echten Fernseher getestet (24.10.2026, Pixel 6a → TCL 75Q7C mit Google TV): DASH spielt, Pause/Springen. Vom Mac/Windows aus mit echtem Fernseher noch offen (derselbe Rust-Teil). Rust-Tests: Nachrichtenformat, Listen-Umschreiben (HLS und DASH), echte Kette (cargo test lan_chain -- --ignored), Stücklager am Fernseher (cargo test live_tv -- --ignored, siehe lan.rs). position_ms() gibt die Stelle des Fernsehers an lan.rs.

10. Lokale Daten

Alles liegt im localStorage der WebView (persist.svelte.ts: loadJson, saveJson, persist speichert bei Änderung, entprellt).

Beim Laden werden gespeicherte Einstellungen abschnittsweise mit den Standardwerten zusammengeführt. Neue Felder bekommen so automatisch ihren Standard. Speicherorte auf dem Mac: ~/Library/WebKit/io.github.mhd6271.flimmer/… /localstorage.sqlite3 (Werte als UTF-16).

11. Externe Dienste

12. Live-Chat

livechat.ts wandelt YouTube.js-Chat-Aktionen in eigene Typen (ChatMessage, ChatBanner, ChatChange) und wendet Änderungen an (applyChange, höchstens CHAT_LIMIT Nachrichten). LiveChat.svelte startet getLiveChat(), zeigt an und verbindet neu (nach 5, 15, 45 s).

YouTube.js' LiveChat fragt live_chat/get_live_chat in YouTubes Takt ab, verteilt die Nachrichten gleichmäßig und holt alle 5 s die Zuschauerzahl (updated_metadata), wie die Webseite. Chat-Wiedergaben beendeter Streams zeigt Flimmer nicht.

• Die Startantwort ('start') enthält die letzten ~70 Nachrichten und die Ansichten Top-Chat/Live-Chat. YouTube.js gibt sie nicht als chat-update aus; Flimmer verarbeitet sie selbst. applyFilter wechselt die Ansicht, die nächste Antwort ist wieder 'start'.
• Nach einem Netzausfall: HTTP 400 „invalid argument“, YouTube.js versucht 10× mit derselben Kennung und meldet 'end' → Flimmer verbindet mit der Start-Kennung aus /next neu (sie gilt auch nach Minuten noch).
• Platzhalter ersetzt YouTube später (ReplaceChatItemAction). Manche Kanäle haben einen Chat nur für Mitglieder.

13. Updates und Veröffentlichen

Updater (Desktop)

• tauri-plugin-updater, Endpunkt https://github.com/mhd6271/flimmer-releases/releases/latest/download/latest.json, öffentlicher Schlüssel in tauri.conf.json. Nur Desktop (Android/iOS haben keinen Tauri-Updater; Android siehe unten).
• updates.svelte.ts: startUpdateChecks prüft beim Start und alle 6 Stunden; Modus notify (Hinweis im Layout), auto (still installieren, gilt ab Neustart), off. installUpdate, restartNow.
• Windows installiert passiv (installMode: passive). .deb/.rpm aktualisiert die Paketverwaltung.

Updater (Android, seit 0.5.18)

• Kein Tauri-Updater auf Android. MainActivity (Brücke FlimmerAndroid): checkUpdate() liest dieselbe latest.json (HttpURLConnection im Hintergrund-Thread; GitHub leitet auf einen anderen Host weiter) und meldet { type: 'latest', version, notes, url } als Ereignis flimmer-update. APK-Adresse aus dem Schlüssel android.url auf oberster Ebene – nicht unter platforms, dort verlangt der Tauri-Updater je Eintrag eine Signatur; fehlt er (Releases bis 0.5.17), wird die Adresse aus der Version gebaut.
• installUpdate(url): Download nach cacheDir/updates/<Dateiname aus der Adresse> mit Fortschritt (progress); eine vollständig geladene Datei (Marke .ok mit der Größe) wird wiederverwendet – nach abgebrochenem Installer-Dialog lädt „Nochmal“ nicht noch einmal. Dann Installer über FileProvider + ACTION_VIEW (installer). Fehlt „Unbekannte Apps installieren“ (canRequestPackageInstalls), zuerst ACTION_MANAGE_UNKNOWN_APP_SOURCES (permission), Fortsetzung in onResume. Google TV öffnet dabei die Liste aller Apps statt des Schalters für Flimmer. Recht REQUEST_INSTALL_PACKAGES im Manifest.
• Sicherheit: keine eigene Signaturprüfung nötig – Android installiert nur mit demselben APK-Schlüssel.
• updates.svelte.ts: Android-Weg in checkForUpdate/installUpdate, Versionsvergleich newer, canUpdate; Modus auto wirkt wie notify. Kommt die App zurück (visibilitychange), fallen installer/permission auf idle zurück – sonst bliebe ein abgebrochener Installer stehen und der 6-Stunden-Zyklus prüfte nie mehr. Der Hinweis im Layout wählt sich auf dem Fernseher selbst an (focusOnTv).
• Testen ohne Release: nur in der Debug-Fassung liest checkUpdate die Adresse aus files/update-url.txt (adb shell "run-as io.github.mhd6271.flimmer sh -c 'cat > files/update-url.txt'"), z. B. eine latest.json vom Mac (python3 -m http.server) mit einer höher nummerierten, mit dem Release-Schlüssel signierten APK. Zurück zur niedrigeren Version: adb install -r -d (geht, solange die installierte Fassung debuggable ist).

Schlüssel

Geht der Update-Schlüssel verloren, nehmen installierte Apps keine Updates mehr an. Ein neuer Android-Schlüssel zwingt zum Deinstallieren. Beide nie committen oder ausgeben, Sicherungskopien aufbewahren.

Veröffentlichen

1. Version in package.json, src-tauri/tauri.conf.json, src-tauri/Cargo.toml (about.ts liest sie aus package.json) erhöhen, committen.
2. Notizen in eine Datei schreiben, dann:

tools/release.sh NOTIZEN.md

Das Skript:

1. prüft, dass die Arbeitskopie sauber ist und es das Release noch nicht gibt;
2. setzt das Tag vX.Y.Z im privaten Repo und pusht es → GitHub Actions baut Windows (NSIS, MSI) und Linux (AppImage, deb, rpm) signiert;
3. baut die Mac-App lokal (--bundles app) mit Update-Signatur, packt das Zip;
4. baut die Android-APK lokal (nur wenn keystore.properties existiert);
5. wartet auf den CI-Build (fragt alle 30 s, höchstens 40 min, übersteht Netzaussetzer) und lädt die Dateien;
6. schreibt latest.json (darwin-aarch64, windows-x86_64, linux-x86_64 mit Signaturen);
7. legt das Release in mhd6271/flimmer-releases als Entwurf an, lädt jede Datei einzeln mit Wiederholungen hoch (große Dateien brachen mit HTTP 408 ab) und veröffentlicht erst am Ende. So sieht keine App eine latest.json, deren Dateien noch fehlen.

Ein Release hat 15 Dateien. Die öffentlichen Releases liegen getrennt, weil die Pipeline des privaten Repos ohne zusätzlichen Zugangsschlüssel nicht ins öffentliche schreiben darf; das Skript nutzt die gh-Anmeldung.

14. Build-Profil (gemessen)

src-tauri/Cargo.toml:

[profile.release]
codegen-units = 1
lto = true
opt-level = 3
panic = "abort"
strip = true

Am 18.10.2026 lokal gemessen (MacBook Air M5, nur der Rust-Teil der Release-Fassung):

Entscheidung: so lassen. Ein Release dauert insgesamt 20–25 Minuten; die meiste Zeit gehört dem CI-Build (Windows, Linux mit Abhängigkeiten, Bündeln) und dem Hochladen. Das lockere Profil spart dort geschätzt nur 1–2 Minuten, macht aber jede Programmdatei ein Drittel größer, also auch jeden Download und jedes Update. Für schnelles Arbeiten gibt es tauri dev (Debug-Profil). Lohnt sich später ein Wechsel, dann nur gemessen und über ein eigenes Profil, nicht durch Lockern von release.

15. Android

Einmalig einrichten: Java 17 (brew install openjdk@17), Android-Befehlszeilenwerkzeuge (brew install android-commandlinetools), per sdkmanager Platform-Tools, Android 35, Build-Tools 35, NDK 27.2, Rust-Ziele (rustup target add aarch64-linux-android …). Die Pfade setzt tools/android-env.sh.

source tools/android-env.sh && deno task tauri android build --apk --target aarch64

Ergebnis unter src-tauri/gen/android/app/build/outputs/apk/universal/release/. tools/release.sh baut die APK mit.

• Ab Android 7, aarch64 und armv7 in einer APK (Google TV läuft oft nur mit 32 Bit, armeabi-v7a). Dafür: CARGO_TARGET_DIR="$PWD/src-tauri/target.noindex" deno task tauri android build --apk --target aarch64 --target armv7 – ohne das eigene Zielverzeichnis landet die armv7-Bibliothek in src-tauri/target und fehlt im APK; vorher src-tauri/gen/android/.gradle/configuration-cache löschen, sonst nimmt Gradle die alte ABI-Liste (nur arm64). tools/release.sh macht beides und prüft mit unzip -l, dass beide lib/<abi>/ drin sind.
• Google TV / Android TV (seit 0.5.18): Manifest mit android.hardware.touchscreen und faketouch als „nicht nötig“ (sonst „nicht kompatibel“), LEANBACK_LAUNCHER, Banner @drawable/banner (aus src-tauri/icons/flimmer-tv-banner.svg, erzeugt in tools/android-icons.sh). TV-Modus in src/lib/tv.ts (isTV: Kennung „Android TV/Google TV/Smart TV/BRAVIA/AFT…“ oder Android ohne Zeiger), Klasse tv am <html>:
  • Fernseher bekommen die große Ansicht (isMobile im Layout = Handy und nicht TV); die Android-Besonderheiten der Wiedergabe gelten weiter über isMobile aus net.ts.
  • Eigene räumliche Navigation (die WebView bewegt den Fokus mit den Pfeiltasten nicht zwischen Elementen): nächstes Element in Pfeilrichtung, Wertung = Abstand + 2× seitlicher Abstand der *Kanten* (Mitten ließen unter dem breiten Video ein mittig liegendes, weit entferntes Element gewinnen) + 0,1× Versatz zur linken Kante. Zuerst zählt, was seitlich überlappt (gleiche Spalte/Zeile), alles andere erst, wenn es nichts davon gibt (+1000) – sonst gewann aus einer Karte das 29 px höhere Seitenleisten-Element gegen die Karte darüber (127 px wegen des Titeltexts). Von Kopfzeile/Seitenleiste aus zählen im Inhalt nur sichtbare Elemente (keine über den Rand gescrollten Karten), und „runter“ aus der Kopfzeile führt in den Inhalt, nicht in die Seitenleiste. Elemente *auf* dem aktuellen (Knopf auf dem Video) erreicht man mit „runter“. data-tv-skip überspringt (Titel- und Kanal-Link der Karte, „Später ansehen“, ✕); data-tv-column (Seitenleiste) lässt nach unten nicht hinaus. Nahe am Rand scrollt die Auswahl in die Mitte (reveal).
  • Textfelder werden beim Darüberfahren nur gesperrt angewählt (readOnly, sonst öffnet Android sofort die Tastatur); OK entsperrt. OK auf Häkchen/Optionsfeld = Klick (Chromium schaltet sie nur mit der Leertaste).
  • Startauswahl nach jedem Seitenwechsel (focusContent: erstes Video, sonst vorläufig das erste Element, das später ersetzt werden darf) und nach dem Laden einer Liste (focusFirstIn, Paged). Aus einem Textfeld holt das Programm die Auswahl nur in den 15 s nach dem Abschicken der Suche (markSubmitted) – nicht, wenn der Nutzer das Suchfeld selbst angewählt hat, während eine Liste noch lädt.
  • Player.svelte lässt Pfeiltasten in Ruhe, die tv.ts schon verbraucht hat (event.defaultPrevented) – sonst spulte jede Bewegung zwischen den ähnlichen Videos das laufende Video um 5 s.
  • candidates() misst nur Elemente in der Nähe des Bildschirms (±2 Höhen), getComputedStyle erst danach.
  • Fokus sichtbar mit :root.tv :focus – vom Programm gesetzter Fokus gilt in der WebView nicht als :focus-visible. Die WebView braucht dafür selbst den Android-Fokus: MainActivity ruft requestFocus(); sonst holt sich die WebView den Fokus erst mit dem ersten Tastendruck, und der setzt die Auswahl zurück.
  • Chromiums Video-Bedienelemente blendet es bei fokussiertem Video nie aus (großer Pause-Knopf stand dauerhaft im laufenden Bild, auch im Vollbild) → showControls: video.controls nur 3 s nach einem Tastendruck, nach playing (nur als Weiterspielen nach einer Pause) und beim Vollbild-Wechsel, bei pause dauerhaft. Ausblenden über einen Timer in showControls und timeupdate: stockt ein 4K-Video im Vollbild, kommt kein timeupdate, und jedes playing nach dem Stocken stellte die Uhr neu – das Pause-Zeichen blieb stehen (Nutzer 21.10.2026). Das controls-Attribut in Player.svelte ist statisch, Svelte setzt es nicht zurück. Im Vollbild bleibt das Attribut aus (showControls setzt es dort auf false, toggleFullscreen vor dem Anfordern): Chromium zeigt die Leiste im Vollbild ohnehin – beim Sprung und bei Pause, nach playing blendet es selbst nach 3 s aus. Ein im Vollbild an- und wieder abgeschaltetes Attribut ließ sie dagegen bis zum nächsten Medienereignis stehen (TCL, 21.10.2026, mit Devtools gemessen: controls=false + Sprung → 4 s später weg; an → aus → bleibt).
  • Im Vollbild hat das Video nie den Fokus (unfocusFullscreenVideo bei fullscreenchange, focusin, playing, showControls): Chromium blendet die Leiste bei fokussiertem Video nie aus – nach Pause/Weiter stand die Zeitleiste bis zum nächsten Video (Nutzer 21.10.2026; per Devtools: Vollbild, controls aus, activeElement = VIDEO).
  • Der TCL rendert die Oberfläche mit 960 CSS-Pixeln Breite (Android-Override 1920×1080, Pixeldichte 2) – Layout wie ein schmales Fenster prüfen. Die linke Spalte der Kopfzeile ist deshalb minmax(max-content, 1fr) (vorher 180 px: der Vorwärts-Pfeil lag 17 px unter dem Suchfeld, per getBoundingClientRect am TV gemessen).
  • Tastatur-Kürzel: Player.svelte ignorierte alle Kürzel bei fokussiertem Video (auf dem TV immer) – jetzt nur noch Leertaste/Pfeile (die erledigen Bedienleiste bzw. tv.ts); F im Vollbild kommt als flimmer-key „f“ aus MainActivity (KEYCODE_F) und verlässt es (videoKey).
  • Großer Play/Pause-Knopf in der Bildmitte: auf dem Fernseher per CSS aus (video::-webkit-media-controls-overlay-play-button, Player.svelte), die Zeitleiste bleibt – Nutzer 21.10.2026: „Es reicht start/stop zu drücken. Wozu den Button“.
  • Zoom: onKey schluckt Strg/Cmd + Plus/Minus/0, wheel mit Strg wird abgefangen; MainActivity schaltet auf Leanback-Geräten supportZoom/builtInZoomControls aus (Bluetooth-Tastatur zoomte die Oberfläche).
  • Videostart: stream.ts prefetchStreamSoon – ruht die Auswahl (focusin, nur auf dem Fernseher; nicht beim Überfahren mit der Maus) 1,5 s auf einer VideoCard, wird der Strom vorgeladen – nur über den normalen Weg (prefetchStream(id, true) → getStream, nie SABR/BotGuard); scheiterte das, macht loadStream beim Start den vollen Ablauf. Gemessen am TCL 22.10.2026: Wiedergabe 2,0 s nach dem Start (vorher bis 17 s) (ein Timer für alle Karten, Vorrat ≤ 8; das Durchwandern einer Liste löst keine Anfragen aus). +layout.svelte lädt shaka-player außerhalb von WebKit 4 s nach dem Start im Leerlauf. Player.svelte protokolliert „Metadaten … nach x s“ und „Wiedergabe läuft … x s nach dem Start“, shaka.ts „DASH (Modul/Manifest/Laden ms)“ – damit lässt sich ein langsamer Start (TCL: 17 s bei 4K) im Protokoll der Einstellungen zuordnen. Geprüft (Deno, 21.10.2026): die Adressen des VISIONOS-/IOS-Clients brauchen keine n-Entschlüsselung, toDash ruft das Player-Skript dort nicht auf – die Entschlüsselung ist nicht die Ursache.
  • Qualität: eingebettet höchstens 1080p (TV_EMBEDDED_MAX, displayCap in shaka.ts – autoCap/chosenCap gelten für shaka und SABR), im Vollbild die gewählte; Player.svelte wendet sie bei fullscreenchange neu an. Grund: Chromium rechnet eingebettete Videos durch die Grafikeinheit in den Kasten, im Vollbild gehen sie als eigene Ebene direkt an den Bildschirm – 4K60 ruckelte eingebettet auf dem TCL, im Vollbild nicht; die Android-Oberfläche des Fernsehers läuft mit 1920×1080 (wm size: Override).
  • Video: OK = Pause, links/rechts ±10 s, Medientasten. Im Vollbild kommen Tasten nicht in der Seite an (sie gehen an Chromiums Vollbild-Ansicht) – MainActivity.dispatchKeyEvent meldet OK/links/rechts/Medientasten als Ereignis flimmer-key. Nach dem Vollbild zurück zur zuletzt gewählten Stelle.
  • Mini-Player bleibt: Elemente, deren Mitte er verdeckt, sind keine Ziele (covered, .dock.active), reveal nimmt seine Oberkante als unteren Rand; auf dem TV zusätzlich ⏯ in seiner Leiste. Die Videoseite beginnt beim Video, nicht bei den ähnlichen Videos (auch Karten). System-Bild-in-Bild braucht die Funktion android.software.picture_in_picture – der TCL-Fernseher hat sie nicht (pm has-feature).
  • Testen: Debug-APK mit dem Release-Schlüssel neu signieren (gleiche Signatur, Daten bleiben), dann adb forward tcp:9333 localabstract:webview_devtools_remote_<pid> und per Devtools-Protokoll document.activeElement auslesen; Tasten mit adb shell input keyevent 19/20/21/22/23/4.
• Emulator: emulator -avd Flimmer_Pixel6 -gpu host (mit swiftshader zeichnet der WebView Bildreste). In Bildschirmfotos (adb exec-out screencap) ist das Video schwarz – Hardware-Videoebene, kein Fehler.
• Verteilung nur als APK über flimmer-releases; Updates in der App seit 0.5.18 (Kapitel 13).
• Wiedergabe über shaka/DASH (Android-WebView kann kein HLS).
• MainActivity.kt (src-tauri/gen/android/app/src/main/java/io/github/mhd6271/flimmer/):
  • Statusleiste und Ränder.
  • FullscreenChromeClient: Tauris RustWebChromeClient beendet Vollbild sofort, deshalb eine eigene Hülle darum (onShowCustomView, Querformat, Leisten aus, Zurück beendet).
  • JavaScript-Brücke FlimmerAndroid.setPlaying(playing, width, height): Der Player meldet, ob ein Video läuft und in welchem Format. Beim Verlassen der App geht Flimmer ins Bild-in-Bild (setAutoEnterEnabled, onUserLeaveHint). Der WebView bleibt dabei aktiv (Tauri pausiert ihn sonst), die Seite zeigt nur das Video (html.pip in app.css).
  • Videos starten ohne Fingertipp (mediaPlaybackRequiresUserGesture = false).
  • Wird das kleine Fenster vergrößert, schickt die Activity flimmer-fullview; die Seite geht ins Vollbild (enterVideoView). Zurück beendet es (leaveVideoView).
  • armBack() meldet den Zurück-Rückruf jedes Mal neu an. Sonst gewann Wrys eigener Rückruf und das Vollbild der WebView verschluckte Zurück.
• Hintergrund-Wiedergabe (PlaybackService.kt, seit 0.5.11, Einstellung player.background):
  • Der Player meldet über FlimmerAndroid.setSession(state, title, artist, artwork, background) den Zustand (playing, paused, ended = gleich kommt das nächste, idle). Ein Vordergrund-Dienst (Typ mediaPlayback) zeigt eine Notification.MediaStyle mit eigener MediaSession (nur Framework-APIs, keine androidx.media) und hält Prozessor und WLAN wach, solange etwas spielt oder das nächste lädt.
  • Tasten (Benachrichtigung, Sperrbildschirm, Kopfhörer) gehen als Ereignis flimmer-media an die Seite (play, pause, next, stop); next wirkt wie das Ende des Videos (Autoplay/Playlist).
  • Chromium hält Videos mit Ton an, sobald die WebView unsichtbar wird (Bildschirm gesperrt). Deshalb meldet MainActivity der WebView nach onStop jede Sekunde dispatchWindowVisibilityChanged(VISIBLE) und onResume(), solange etwas spielen soll – in den ersten 3 Sekunden alle 50 ms (seit 0.5.13; der Aussetzer beim Sperren schrumpfte damit von bis zu 1 s auf meist 0, höchstens ~15 ms), und spielt nach einem System-Anhalten nach 50 statt 300 ms weiter. Ein Anhalten im Hintergrund, das nicht über die Steuerung kam, gilt als vom System (resumeWanted) – die App spielt dann sofort weiter.
  • Pausiert der Nutzer im Hintergrund, legt MainActivity die WebView wie Tauri schlafen; „Abspielen“ weckt sie.
  • Der Dienst wird nur gestartet, solange die App sichtbar ist (Android 12+ verbietet den Start aus dem Hintergrund); danach gehen Änderungen direkt an die laufende Instanz.
  • Getestet im Emulator: 45 s gesperrt weiter abgespielt, Pause/Abspielen/Nächstes über adb shell cmd media_session dispatch ….
• Musikhör-Modus und Überblenden (seit 0.5.13, Einstellung player.crossfade, 0 = aus; nur Android, nur bei gesperrtem Bildschirm – Wunsch des Nutzers, auf dem Desktop/AirPlay ergäbe es keinen Sinn):
  • MainActivity meldet flimmer-background (true nach onStop, außer im kleinen Fenster; false bei onStart).
  • Startet im Hintergrund ein neuer Song, lädt shaka nur den Ton (AttachOptions.audioOnly → manifest.disableVideo). Beim Entsperren lädt der Player denselben Song mit Bild an derselben Stelle neu (backToVideo, resumeFrom) – ohne Pause: Ein SidePlayer lädt 2,5 s voraus, startet genau, wenn der Haupt-Player dort ankommt, überbrückt das Neuladen und blendet in 0,3 s aus, sobald das Bild spielt.
  • Überblenden (Player.svelte: crossfadeTick, prepareFade, startFade, finishFade, takeOver): 20 s + Überblendzeit vor dem Ende (musicEnd: ein übersprungener SponsorBlock-Abschnitt bis zum Schluss zählt als Ende) holt peekNext() das nächste Video (Playlist oder pickAutoplay), prefetchStream lädt den Stream (die Video-Seite bekommt ihn danach aus diesem Zwischenspeicher, keine zweite Anfrage), SidePlayer (player/crossfade.ts) spielt ihn in einem unsichtbaren <audio> mit eigener shaka-Instanz. In den letzten N Sekunden steigen und fallen die Lautstärken (element.volume, alle 200 ms). Am Ende setzt der Player playback.handover, hält an und ruft onended; Video-Seite bzw. playNextInMini nehmen genau dieses Video ohne Vorlauf, der Haupt-Player springt an die Stelle des Ton-Players (loadedmetadata) und blendet ihn bei playing in 0,4 s aus.
  • Während der Übergabe meldet der Player Android den Zustand ended, sonst hielte MainActivity das Anhalten für ein System-Anhalten und spielte den alten Song weiter.
  • Am Pixel 6a geprüft: vorgeladen, 8 s überblendet, Übernahme bei 0:08 (Nutzer: „absolut geil, der Übergang“).
• Fallen: Kopfzeilen und POST-Inhalte eigener Protokolle gehen im WebView verloren → Byte-Bereiche als range= in der Adresse (shaka.ts; offene Bereiche bytes=N- mit dem Ende aus clen=), SABR-POSTs über das HTTP-Plugin; der Proxy meldet dort 206 als 200. mask-image vermeiden.

Google Play (seit 22.10.2026 vorbereitet)

Alles für einen geschlossenen Test liegt in play/ (play/LIESMICH.md: Schritte in der Play Console, Antworten für Datensicherheit, Inhaltsbewertung, Vordergrunddienst, Entscheidung zur App-Signatur, Richtlinien-Risiko).

• tools/play-aab.sh baut ein AAB für arm64-v8a, armeabi-v7a und x86_64 mit FLIMMER_PLAY=1 und prüft es (keine REQUEST_INSTALL_PACKAGES, alle drei Architekturen, signiert) → play/out/Flimmer-<Version>-play.aab (nicht im Git).
• FLIMMER_PLAY=1 (build.gradle.kts): BuildConfig.PLAY_STORE, Manifest-Zusatz src/play/AndroidManifest.xml entfernt REQUEST_INSTALL_PACKAGES (tools:node="remove", nur Release). MainActivity.playStore() meldet das an die Seite; updates.svelte.ts (playStore, androidUpdater) schaltet das eigene Update ab, die Einstellungen zeigen „Neue Versionen kommen über Google Play“ – ohne Verweis auf GitHub-APKs (wäre selbst ein Verstoß). „Über Flimmer“ sagt dort „Videoplayer mit SponsorBlock und DeArrow“ statt „YouTube ohne Werbung“ und verlinkt die Datenschutzerklärung. Gradle merkt sich Umgebungswerte in .gradle/configuration-cache – das Skript löscht ihn vorher und nachher.
• Grafiken: tools/play-grafik.sh aus play/grafik/*.svg (Symbol randlos 512², Vorstellungsgrafik 1024×500, TV-Banner 1280×720; JPEG, weil Play dort keine Transparenz will). Fotos: tools/play-shots.sh mit tools/play-shots.swift (WebKit, fremder User-Agent für Handy/Fernseher, Animationen aus, Bilder sofort laden; NASA/ESA-Inhalte) gegen den Browser-Modus. Belegt etwas Port 8790, geht der Entwicklungs-Proxy auf einen anderen: FLIMMER_DEVPROXY_PORT=8791 deno task devproxy und VITE_DEVPROXY_PORT=8791 deno task dev.
• Datenschutzerklärung: DATENSCHUTZ.md → https://muehlbronner.de/projekte/flimmer/datenschutz/ (über tools/doku-html.ts --site, wie Anleitung und Entwicklerdoku).

16. iOS

Noch nicht verteilt; wartet auf das Apple-Entwicklerkonto (Team-ID).

Einmalig einrichten: Xcode aus dem App Store mit iOS-Plattform, sudo xcode-select -s /Applications/Xcode.app, Rust-Ziele aarch64-apple-ios und aarch64-apple-ios-sim, brew install xcodegen cocoapods.

• Projekt unter src-tauri/gen/apple, erzeugt mit tauri ios init; aus project.yml erzeugt xcodegen auch die Info.plist: Ton im Hintergrund (UIBackgroundModes audio), lokales Netzwerk für Chromecast (NSLocalNetworkUsageDescription, NSBonjourServices _googlecast._tcp).

Bauen für den Simulator:

tools/ios-build.sh

Das Skript setzt CARGO_TARGET_DIR (Xcodes Bauschritt übergeht .cargo/config.toml, Tauri suchte die Bibliothek sonst vergeblich in target.noindex) und legt .metadata_never_index an, damit Spotlight die Simulator-Apps nicht als weitere „Flimmer“ anbietet. tools/ios-build.sh --debug baut die Debug-Fassung. Starten: xcrun simctl install booted …/release-iphonesimulator/Flimmer.app, dann xcrun simctl launch booted io.github.mhd6271.flimmer. Der erste Start im frischen Simulator bleibt einige Sekunden weiß.

• Symbole: Quelle ist das Maskottchen (Röhrenfernseher) in src-tauri/icons/flimmer.svg; nach swift tools/render-icon.swift && deno task tauri icon src-tauri/icons/flimmer.png noch tools/android-icons.sh (adaptives Symbol: Vordergrund nur der Fernseher aus flimmer-android-fg.svg, Hintergrund #1C1640 – sonst legt tauri icon die Kachel auf Weiß) und tools/ios-icons.sh ausführen. Das kleine Logo in der App ist Logo.svelte.
• iOS-Symbole: tools/ios-icons.sh aus der randlosen Fassung src-tauri/icons/flimmer-ios.svg (als RGBA rendern, über sips/JPEG ohne Alphakanal ablegen). tauri icon liefert für iOS die abgerundete Desktop-Fassung, deren durchsichtige Ecken iOS schwarz füllt.
• Geprüft im Simulator (iPhone 18 Pro): Suche, Wiedergabe über den Systemplayer, Originalton, SponsorBlock-Leiste. Touch-Anpassungen: Knöpfe ohne Hover sichtbar (@media (hover: none)), 16 px in Eingabefeldern (sonst zoomt Safari).
• Offen: echtes iPhone, Bild-in-Bild und Hintergrund, Signatur, iPad (bekommt noch den Abstand der Mac-Titelleiste).

17. Testen und Diagnose

• deno task check und deno task test (16 Tests ohne Netz: Links, HLS-Listen, Tonspur, Untertitel, Import …).
• Rust: cargo test in src-tauri (CASTV2-Nachrichten, Listen-Umschreiben), cargo test lan_chain -- --ignored (echte Kette über die WLAN-Adresse).
• Sparsam testen. Nach etwa einer Stunde vieler Abrufe hat YouTube den Bot-Schutz ausgelöst. Nicht gleichzeitig im Browser und in der App abspielen.
• Testvideos: _2i-dhRl9wo (Sponsor 1:15–1:38), sonst deno run -A tools/find-sponsor.ts. Live-Streams: deno run -A tools/find-live.ts "chill rap radio" (Live-IDs veralten schnell).
• Svelte 5 delegiert Ereignisse: In Browser-Tests dispatchEvent(new Event('change', { bubbles: true })).
• Hintergrundaufgaben (Vite, devproxy, Emulator, Simulator) nach dem Testen beenden.

Diagnose-Skripte (tools/)

Wenn YouTube etwas ändert

1. Protokoll der App lesen (Einstellungen → Protokoll, oder Terminal).
2. Mit deno task probe (Format-Adressen und HLS je Client) und tools/probe.ts (SABR) prüfen, was gerade geht. Was die App selbst anfragt: window.__flimmerNet (Devtools) – die letzten 500 YouTube-Anfragen aus proxyFetch, nur Zeit, Methode, Adresse ohne Parameter. Gezählt 18.10. am Google TV: Suche = 1× search + oembed je sichtbarer Karte; Video = 1× /next + 1× /player (ohne SABR-Umweg). Live: probe-live.ts ID, probe-live-detail.ts ID, probe-live-segments.ts ID, probe-livechat.ts ID [s] [all|switch], probe-livechat-expiry.ts ID.
3. YouTube.js aktualisieren (deno outdated, deno add npm:youtubei.js@latest), dann deno task check und deno task test.
4. In der App unter Einstellungen → Wiedergabe → Für Fortgeschrittene Abspieltechnik und Videostrom erzwingen.
5. Parser-Fehler zeigen sich meist in yt.ts (videosFrom, Lockup-Knoten); probe-lockup.ts/probe-nodes.ts zeigen die neuen Strukturen.

18. Stolperfallen

• Svelte-5-Effekte: Laden in $effect mit untrack(...), sonst lädt jede Verlaufs- oder Einstellungsänderung neu. Paged lädt neu, wenn sich load ändert – Aufrufer übergeben $derived.by(() => { const x = wert; return () => lade(x); }) und lesen die Werte außerhalb der zurückgegebenen Funktion. $derived(() => lade(wert)) liest erst beim Aufruf und hat keine Abhängigkeit (zweite Suche lud in der Mac-App nicht, 18.10.2026). Nach einem Ladefehler kein automatisches Nachladen, sondern ein Knopf „Nochmal versuchen“ (sonst Endlosschleife).
• Scroll-Position: Gescrollt wird <main>, nicht das Fenster; SvelteKit setzt beim Seitenwechsel nur das Fenster zurück. +layout.svelte merkt sich die Position je Verlaufseintrag (beforeNavigate), setzt bei neuen Seiten auf oben und stellt bei Zurück/Vorwärts die alte Stelle wieder her (mit Nachversuchen, solange Listen nachladen). Vorher landete man nach einem Klick unten bei den ähnlichen Videos mitten auf der neuen Video-Seite.
• Listen ohne Dubletten: {#each} mit Schlüssel stürzt bei doppelten IDs ab; feedVideos entfernt Dubletten.
• YouTube.js übergibt Kopfzeilen und Body im zweiten fetch-Argument; ein Request-Objekt würde den User-Agent entfernen.
• HTTP-Plugin braucht das Feature unsafe-headers; Fensterziehen braucht core:window:allow-start-dragging.
• CORS: googlevideo sendet keine CORS-Kopfzeilen, i.ytimg.com und sponsor.ajay.app schon.
• Testgruppen: Manche Sitzungen liefern über Format-Adressen nur ~5 MB (danach 403); HLS geht.
• shaka: Schema media muss bei shaka angemeldet sein; alten Abspieler mit await destroy() beenden, bevor der nächste startet.
• Live: toDash() wirft bei laufenden Streams → ANDROID_VR-Manifest mit /mpd_version/7, in shaka über die echte Adresse, defaultPresentationDelay 15 s. Live hat keine Kommentare.
• BotGuard prüft die Seitenadresse: Im Hauptfenster der App gibt es nur das Ersatz-Token (Index 3, unbrauchbar) – deshalb der youtube.com-Frame (Kapitel 9). Ein user-agent- oder sonstiger eigener Header im fetch auf media:// ließ unter macOS jeden Abruf scheitern (CORS-Vorabanfrage) – Kennungen nur über die Adresse oder einen Befehl.
• Spotlight: Bauordner target.noindex; nach Umbenennen cargo clean (Build-Skripte speichern absolute Pfade).
• confirm()/alert() funktionieren in der WebView nicht zuverlässig → eigene Rückfrage in der Oberfläche.
• Mehrere „Flimmer“ auf dem Mac: Die App aktualisiert sich dort, wo sie liegt. Eine zweite Kopie in Downloads bleibt alt. Simulator-Apps sind über .metadata_never_index aus Spotlight ausgeschlossen.
• Touch: Ein erster Tipp auf etwas, das bei Hover erscheint, gilt auf iOS nur als Hover. Hover-Effekte nur unter @media (hover: hover).

19. Sicherheit

• Netzrechte (src-tauri/capabilities/default.json): Das HTTP-Plugin darf nur youtube.com, m.youtube.com, youtubei.googleapis.com, jnn-pa.googleapis.com, *.googlevideo.com und sponsor.ajay.app erreichen. Updater und Neustart nur auf dem Desktop (desktop.json).
• Medien-Proxy und WLAN-Server reichen nur an googlevideo weiter (media::allowed). Der WLAN-Server nutzt zufällige 128-Bit-Pfade.
• Entschlüsselung von YouTubes Player-Code läuft in einem Web Worker mit Zeitlimit (sandbox.ts); bei Zeitüberschreitung wird der Worker beendet.
• BotGuard läuft nur im SABR-Weg und seit 0.5.29 in einem Frame fremder Herkunft (youtube.com): kein Zugriff auf die App-Seite, keine Tauri-Befehle, nur postMessage mit geprüfter Herkunft.
• CSP ist null (offen). Eine Content-Security-Policy ist ein offener Punkt.
• Chromecast-TLS prüft das Zertifikat nicht (Geräte haben selbst signierte); nur im lokalen Netz.
• Update-Pakete sind signiert; die App installiert nur gültig signierte.

20. Symbol-Referenz

src/lib

src/lib/player

Komponenten

Player.svelte (Technikwahl, Tasten, SponsorBlock, Untertitel, Qualität, Ton, Cast), SegmentBar.svelte, LiveChat.svelte, Comments.svelte + CommentReplies.svelte, Paged.svelte (Liste mit Nachladen), VideoCard, ChannelCard, PlaylistCard, QueuePanel, SaveMenu, SubscribeButton, HideChannelButton, HomeGreeting (Startseite: Maskottchen-Röhrenfernseher als SVG – schaltet ein, blinzelt, wackelt mit den Antennen, beim Antippen erneut –, Schriftzug mit Röhren-Einschalteffekt und Spruch; reines CSS, läuft einmal, respektiert „weniger Bewegung“), ImportExport, Sidebar, Icon, Logo.

Rust

21. Lizenzen

Alle Bausteine sind freizügig lizenziert: YouTube.js, googlevideo, BgUtils (MIT), shaka-player (Apache-2.0), Tauri (MIT/Apache-2.0), Svelte/SvelteKit (MIT), axum/tokio (MIT), rustls (Apache-2.0/MIT/ISC), mdns-sd (MIT/Apache-2.0). Die Daten von SponsorBlock und DeArrow stehen unter CC BY-NC-SA 4.0: in einer kostenlosen App mit Namensnennung (steht auf der Seite „Über Flimmer“) in Ordnung, für eine kostenpflichtige App braucht es die Erlaubnis des Betreibers. Der SABR-Adapter (sabr-adapter.ts) ist aus dem MIT-lizenzierten Beispiel googlevideo/examples/sabr-shaka-example (LuanRT) angepasst. Die Liste in der App pflegt about.ts. Eine Lizenz für Flimmer selbst ist noch nicht festgelegt.

22. Offene Punkte

• Chromecast vom Mac/Windows aus am echten Fernseher testen (vom Android-Handy aus läuft es seit 0.5.28).
• iOS: Entwicklerkonto, echtes iPhone, Bild-in-Bild/Hintergrund, iPad-Abstand.
• App-Name: „Flimmer“ ist belegt; Kandidaten Klarkino, Kinopane, Guckkiste, Glotzfrei.
• Content-Security-Policy statt csp: null (dann frame-src https://www.youtube.com für den BotGuard-Frame).
• media.rs streamen statt ganz puffern; WLAN-Freigaben früher verfallen lassen.
• „Verlauf löschen“ in den Einstellungen mit Rückfrage.
• Code-Signatur für Windows (SmartScreen), Notarisierung für macOS.
• Weitere Ideen: im Hintergrund nur die Tonspur laden (spart Akku und Daten), Kanal-Suche, Community-Tab, Chat-Wiedergabe beendeter Streams.

Doku pflegen

ANLEITUNG.md und DEVELOPERS.md sind die Quellen. Die HTML-Fassungen entstehen mit:

deno run -A tools/doku-html.ts

Danach beide HTML-Dateien als Artifact neu veröffentlichen. Markdown, HTML und Artifact immer zusammen aktualisieren.