From 81294906c996932b628d1d1d1fdfecfd08b1fa1c Mon Sep 17 00:00:00 2001
From: Patrick <patrick@madebypatrick.nl>
Date: Mon, 5 Oct 2026 13:10:51 +0200
Subject: [PATCH] Hold the reel sourced in the gap before a live stream, and
 name the three starts the probe could not see (issue 100)

FUSIONOF's 2026-10-05 page (build-b019483, the first with the this-run trail,
the detached and audio lines and the scene line in) carries the live-stream
freeze with the hold on, and it is two stalls.

The live stream itself froze because of a hole in the hold: at the swipe TikTok
pauses the reel, sets the reel after the live stream on its spare element, and
only then plays the live stream. In that tick nothing was playing, busy() found
no one, the source went through, and the engine built its pipeline a second and
a half after the live stream's; the live stream never left 5.8 s. On 2026-10-03
the same tick was sourced and the engine happened to build nothing until the
swipe, and that live stream played. busy() now also returns another <video>
that is held, since a held element is the one about to play, and the line says
`hold v1 blob while v5 is held`. currentSrc reads a held URL back too; TikTok's
preloader logged `empty src is invalid` three times, each after a hold.

The reel in front of the live stream froze exactly as on the 3rd: the combined
avc1+mp4a codec ask, the audio-only appsrc pipeline within half a second, the
reel stopped with 49 s buffered, and the widened probe saw nothing: no (audio),
no detached, scene 2 video / 0 audio / 1 inert detached / 0 iframes. So the
element starts by a call none of the wraps see. NuiMseWatch now wraps play() on
the media prototype (reported for a detached element, an <audio>, or one it has
no event from), the Audio constructor, and setAttribute('src') on a media
element outside the document, pass-through as the rest, and a stall lists six
other elements rather than four.

tools/msehold holds the gap and currentSrc; tools/msewatch holds the three
wraps. INTERNALS: *The gap between two reels, and the pipeline nobody asked
for*, and the 2025-sets state bullet names what the next page decides.
---
 CLAUDE.md                    |  17 +++-
 docs/INTERNALS.md            | 184 ++++++++++++++++++++++++++++++++++-
 src/nui/NuiMseHold.cs        |  45 +++++++--
 src/nui/NuiMseWatch.cs       |  66 ++++++++++++-
 tools/msehold/build-page.py  |  32 +++++-
 tools/msehold/run.sh         |   8 +-
 tools/msewatch/build-page.py |  40 +++++++-
 tools/msewatch/run.sh        |   7 +-
 8 files changed, 373 insertions(+), 26 deletions(-)

diff --git a/CLAUDE.md b/CLAUDE.md
index b3fc64f..636c517 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -136,7 +136,12 @@ the ftyp's brand list; and, since the first trail with the hold in and a freeze
 anyway, to naming an `<audio>` element, writing down a `src` or `load()` on a
 media element that is not in the document and listing it at a stall, a refused
 `srcObject` throwing the engine's own error and leaving no line, and the
-`scene:` line telling a frame of ours from another origin's.
+`scene:` line telling a frame of ours from another origin's. Since the
+2026-10-05 trail (the same freeze with all of that in and nothing stirring) it
+also holds the three starts those wraps never see — `play()` on a detached or
+audio element, `new Audio(url)` with and without an argument, `setAttribute('src')`
+outside the document — to leaving their line, passing the original's return and
+promise back, and being listed at the stall.
 
 ### The one-video harness
 
@@ -150,10 +155,12 @@ tools/msehold/run.sh
 
 It is the one script we inject that changes how a page loads video, so the
 harness drives real MediaSources on real elements and holds it to the contract:
-held while another `<video>` plays, applied on `play()`, read back as if set
-meanwhile, untouched when nothing plays, untouched on `autoplay`, dropped when
-the page takes the source away, a revoke of a held URL surviving to the release,
-`setAttribute` and `srcObject` held the same way. "Opened" means chromium fired
+held while another `<video>` plays or is itself held (the tick between pausing
+one reel and playing the next, the 2026-10-05 live-stream freeze), applied on
+`play()`, read back as if set meanwhile (`src`, the attribute and `currentSrc`),
+untouched when nothing plays and nothing is held, untouched on `autoplay`,
+dropped when the page takes the source away, a revoke of a held URL surviving to
+the release, `setAttribute` and `srcObject` held the same way. "Opened" means chromium fired
 `sourceopen`, which it only does once the engine has the source. It also carries
 a control case worth reading: chromium itself cannot open a source revoked in the
 same task as the set, so that is a shape no working page has.
diff --git a/docs/INTERNALS.md b/docs/INTERNALS.md
index 2efc6bb..d912d7d 100644
--- a/docs/INTERNALS.md
+++ b/docs/INTERNALS.md
@@ -2688,9 +2688,10 @@ Nothing else can happen first — a MediaSource only opens once it is attached,
 there are no `addSourceBuffer`s and no appends to interfere with before that
 point. So the attach is what is held. While another `<video>` on the page is
 playing, a `blob:` or `srcObject` source set on a paused element is remembered
-instead of applied; the element reads it back as if it were set (TikTok's own
-preloader checks `src`, and its `[Preloader_TT] ... empty src is invalid` is what
-it says when it is not); and the moment the page calls `play()` on that element
+instead of applied; the element reads it back as if it were set — `src`,
+`getAttribute('src')` and, since the 2026-10-05 trail, `currentSrc` too (TikTok's
+own preloader checks them, and its `[Preloader_TT] ... empty src is invalid` is
+what it says when one is empty); and the moment the page calls `play()` on that element
 the source is applied for real and the play goes through. Everything after that
 is the page's own sequence — `sourceopen`, its appends, `loadedmetadata`,
 `playing` — on an element that is now the one the viewer is watching. TikTok has
@@ -2700,10 +2701,16 @@ a download.
 
 What it does **not** hold, and why, is the whole safety of it:
 
-- Nothing while no other video is playing. The first reel, and every
+- Nothing while no other video is playing or held. The first reel, and every
   single-player site, is untouched. "Playing" is `!paused && !ended` on another
   `<video>` in the document, which is true from the moment `play()` is called,
-  frame or no frame — exactly when a second pipeline starts to matter.
+  frame or no frame — exactly when a second pipeline starts to matter. "Held"
+  was added after the 2026-10-05 trail (see *The gap between two reels, and the
+  pipeline nobody asked for* below): TikTok's swipe onto a live stream pauses the
+  reel, sources the reel after the live stream, and only then plays the live
+  stream, and in that one tick nothing was playing. A held element is the one
+  about to play, so a source set while one exists is held too, and the line says
+  `while v5 is held` rather than `plays`.
 - Nothing with the `autoplay` attribute. The engine starts that one without the
   page ever calling `play()`, so a held source would never be released.
 - Nothing on a plain URL. The evidence is MSE on TikTok; the sites that work
@@ -2956,6 +2963,154 @@ What decides it, and none of it needs a build:
   That is the engine refusing the stream, and the format on the `init` line is
   what to go to.
 
+### The gap between two reels, and the pipeline nobody asked for
+
+The page FUSIONOF posted on 2026-10-05 (09:40 UTC, a gist, 358 KB) is from
+`build-b019483` — the first with the `this run` trail, the `(audio)` and
+`detached` lines and the `scene:` line all in — and his comment closes the
+2026-10-04 complaint by itself: "That proxy died now using different proxy give no
+errors." The page was fetched at the next launch, so the `previous run` block
+(14:35:32–15:08:25 on the TV's clock, `OnTerminate — closing normally`) is the
+launch with the freeze, the hold on throughout (`hold:` lines beside every swipe),
+and the native output in full. It has two stalls, a minute apart, and they are not
+the same stall:
+
+```
+15:05:43  hold: release v4 after 135.4s (play)             the swipe onto reel v4 (avc1 1024x576, ms6)
+15:05:45  mse: v4 playing t 0.1 ; native: omxtzuhdvideodec21 + omxtzaudiodec21 + mmaudiosink21
+15:05:48  mse: asks mse video/mp4;codecs="avc1.64001f,mp4a.40.2" -> yes
+15:05:48.2 native: GstTZAppSrc -> omxtzaudiodec22 -> mmaudiosink22   NO video decoder
+15:05:50  media: 1024x576 rs4 stuck                       v4 stopped at t 2.3, about 15:05:47-48
+15:05:51  mse: asks hev1.1.6.L93.B0,mp4a.40.2 -> yes ; hold: hold v5 blob while v4 plays (twice: src set again)
+15:05:51  mse: stall v4 ms6 t 2.3 buf 0.1-51.2 | frames 0
+15:05:51  mse: with v5 paused rs0 ns0 ms10, off screen, last no event seen
+15:05:51  mse: with v1 paused rs4 ns1 ms5, detached, last pause 9.5s ago
+15:05:51  mse: scene: 2 video, 0 audio in the document, 1 detached known, 0 iframes (0 not ours)
+15:05:57  mse: still stalled 8s v4: frames +0, appends +0, buf 0.1-51.2
+15:06:00  mse: v1 src ms7, detached                        the reel AFTER the live stream, sourced
+15:06:01  media: playing=0 of 2 ; hold: release v5 after 10.5s (play)      nothing was playing at 15:06:00
+15:06:02  mse: v5 loadstart ms10 ; ms10 add video hev1 + add audio mp4a ; init hvc1 800x1000
+15:06:03  mse: v5 loadedmetadata 800x1000, dur inf ; v5 playing t 0.0 ; waiting t 5.8 ; 15:06:04 playing t 5.8
+15:06:03.4 native: GstTZAppSrc -> omxtzh265dec0 + omxtzaudiodec23 + mmaudiosink23      the live stream
+15:06:04  mse: v1 loadedmetadata 720x960, dur 299.0s, off screen
+15:06:04.9 native: GstTZAppSrc -> omxtzuhdvideodec22 + omxtzaudiodec24 + mmaudiosink24  v1's reel, unheld
+15:06:07  mse: stall v5 ms10 t 5.8 buf 0.1-13.8 | frames 0 ; v5 waiting t 10.0
+15:06:08  media: 800x1000 rs1 ... rs1 stuck                for forty seconds
+15:06:48  hold: hold v4 blob while v5 plays ; 15:06:49 v1 playing t 1.1    the swipe; v1 plays at once
+```
+
+**Stall A, the reel in front of the live stream (15:05:47), is the 2026-10-03
+freeze again, to the second.** Both days: a combined codec ask,
+`video/mp4;codecs="avc1.64001f,mp4a.40.2"`, which appears nowhere else in either
+trail; within half a second of it an appsrc pipeline with an audio decoder and no
+video decoder; the reel on screen stopped with the whole reel buffered, within a
+second before that pipeline's first native line; two to three seconds later the
+HEVC ask and the live element's source, held. A single string naming both tracks
+is what a player with one muxed buffer asks before it starts, and TikTok's reel
+player never asks it — its buffers are added one codec at a time — so the live
+player is what starts at that second. And the widened probe gives the answer it
+was sent for: no `(audio)` line, no `detached` line in the seconds around the
+stall, `scene: 2 video, 0 audio in the document, 1 detached known, 0 iframes`. The
+one detached element is the previous reel, paused ten seconds earlier and inert
+(`rs4 ns1`, it gets `load()` and a new source only after the stall). So the
+pipeline belongs to an element that was never in the document and never went
+through the `src` or `srcObject` setter or `load()`. Three constructions fit
+that and nothing else does: `new Audio(url)`, whose constructor sets the source
+inside the engine without a setter running; `setAttribute('src', …)` on an
+element outside the document, which the hold wraps for `<video>` and the probe
+did not wrap at all; and `play()` on an element the probe has never heard of.
+The in-document `<audio>` elements the probe *did* catch this run (15:00:46 and
+15:00:51, `v2 (audio)`/`v3 (audio) loadstart url v16m.tiktokcdn.com/…`) both
+failed on the spot with `audio error code 4` and opened no pipeline, which says
+the one at the freeze was made some other way. Whether the pipeline is the cause
+or a symptom the clocks cannot settle (the trail is to the second, the playhead
+to a quarter of one), but it is the one thing that moves at the freeze both
+days, and the way the 2026-10-01 freezes killed a reel without the newcomer ever
+playing says the harm is done when the pipeline is built, not when it plays.
+
+**Stall B, the live stream itself (15:06:04), is ours, and it is *Two videos,
+one decoder* through a hole in the hold.** At 15:06:00 TikTok set the reel after
+the live stream on its spare element. At that tick the frozen reel was paused and
+gone from the document, and the live stream had not yet been played — the release
+is at 15:06:01 — so `busy()` found no video playing and the source went through
+(`v1 src ms7, detached`, no `hold:` line). The engine built its pipeline at
+15:06:04.9, a second and a half after the live stream's, and the live stream never
+moved past 5.8 s: it had sought there to its live edge, resumed, and stopped,
+then sought again to 10.0 and sat at `rs1` for forty seconds until the swipe,
+after which v1 played instantly on the pipeline it already had. On 2026-10-03 the
+same tick was sourced the same way (`v1 loadstart blob not ours` at 13:57:29,
+`media: playing=0 of 2`), but the engine built nothing for that reel until the
+swipe onto it at 13:57:52, and that live stream played its twenty seconds. Why the
+engine built early on the 5th and late on the 3rd the trail cannot say — both
+were `preload auto`, off screen, with metadata — and it does not have to: a
+second pipeline next to the one on screen is the harm, and the hold exists to
+stop it being built.
+
+What this build changes, and what it only watches:
+
+- **The hold counts a held element as busy.** `busy()` returns another `<video>`
+  that is playing, as before, and otherwise another `<video>` that is held — the
+  page has given it a source while something played and has not played it yet,
+  so it is the one about to play. The line says which: `hold v1 blob while v5 is
+  held`. On the 5th that holds v1 at 15:06:00; it is released at 15:06:49 when
+  TikTok plays it, exactly as every other held reel was. The chain of holds still
+  only ever starts while a video is playing, and ends where it did: at the page
+  playing, re-sourcing or removing the source of each held element. A page where
+  nothing plays never enters it. The other closing of the gap that was weighed,
+  counting an element that paused within the last few seconds, needs a clock and
+  misses the case in hand (the paused reel had left the document, so no walk and
+  no `pause` event on the document reach it), so it was not built.
+- **`currentSrc` reads the held URL back.** `src` and `getAttribute('src')`
+  already did; `currentSrc` is the engine's own answer and was the empty string
+  while a source was held. TikTok's `[Preloader_TT] onPreloaderError PlayerError:
+  empty src is invalid` landed three times this run, each some seconds after a
+  hold, and that is the property a preloader reads once it stops trusting `src`.
+  Harmless so far — every held reel played — and now closed.
+- **The probe wraps the three starts it could not see**, read-only as ever:
+  `play()` on the media prototype (written down as `v9 play() url host/seg,
+  detached` only for an element that is detached, an `<audio>`, or one the probe
+  has no event from yet — a reel's ordinary `play()` on an element it has been
+  listening to adds nothing a `playing` line does not say); the `Audio`
+  constructor (`v3 (audio) new Audio(url host/seg), detached`, the element
+  remembered so a stall lists it, `Audio.prototype` left as the engine's); and
+  `setAttribute('src')` on a video or audio element outside the document
+  (`v2 setAttribute src url host/seg, detached`). A stall now lists six other
+  elements rather than four, so the detached ones are not pushed off the list by
+  the document's. `tools/msewatch/run.sh` holds all three to passing the
+  original's return and its promise back, `new Audio()` with and without an
+  argument still making an `HTMLAudioElement`, and the elements listed at the
+  stall; `tools/msehold/run.sh` holds the gap (a source set while nothing plays
+  and another element is held is held, released on `play()`, and a source set
+  while nothing plays and nothing is held is untouched) and `currentSrc`.
+
+What the next freeze's page decides, said here first:
+
+- **Stall B does not come back**: a live stream that starts after a reel plays
+  through, with `hold … while vN is held` in front of the reel that used to open
+  under it. If a live stream still stops after its first seconds with a *video*
+  decoder opening beside its own in the native output, the trail will name the
+  element that opened it, and the hold has another path to learn.
+- **Stall A, the reel in front of the live stream**: a `new Audio(…)`,
+  `setAttribute src … detached` or `play() … detached` line in the second or two
+  before the `stall` names the element. A `blob:` source on it is held already
+  (the hold is on the media prototype, audio included) — unless it is an
+  `<audio>`, which the hold's `take()` skips by tag; a plain URL means lifting the
+  plain-URL exemption for that element's kind. Either is a small change to the
+  hold, and the line says which.
+- **Still nothing stirring** with the three wraps in — then there is no element
+  of the page's behind that pipeline, it is the engine's own, and the fix is the
+  recovery set aside in *Two videos, one decoder*: pause and play the stalled
+  element once a stall has lasted a few seconds with nothing on the page to
+  explain it. With the freeze confined to a live stream next in the feed, a
+  hitch of a few seconds once in a session is a different trade from the stop on
+  every reel it was rejected for.
+
+Two smaller things from the same page. The first reel after the TikTok page
+opened stalled at 14:54:31 at `t 1.2 buf 0.1-1.0` — the buffer ends before the
+playhead — which is data not arriving, the proxy, and not the player; the same
+first-reel symptom the 2026-10-03 reading set apart. And the whole run is on a
+third proxy (`198.46.161.42:5092`), through which every other reel played.
+
 ## What the NUI build never asked the engine for
 
 The two builds share `src/common` and nothing else, and everything the ElmSharp
@@ -3944,6 +4099,25 @@ the one its report has to come from. The state is:
   `omxtzuhdvideodec` at all is an engine never handed a frame). The answer that
   would be ours is `ERROR 3`/`ERROR 4` on the census after an `init #1`, and the
   freeze question above is unchanged behind this one.
+  **Both answered on 2026-10-05 (09:40 UTC):** "That proxy died now using
+  different proxy give no errors" closes the refused-video page as the proxy, and
+  the attached page from `build-b019483` carries the live-stream freeze with the
+  hold on and every new line in — see *The gap between two reels, and the pipeline
+  nobody asked for* above for the whole reading. In two lines: the reel in front
+  of the live stream froze exactly as on the 3rd (the combined codec ask, the
+  audio-only pipeline, nothing in the document, nothing detached, no frame), so
+  that element starts by a call the probe did not wrap; and the live stream
+  itself froze because TikTok sourced the reel *after* it in the tick between
+  pausing the old reel and playing the live one, nothing was playing, the hold
+  let it through, and its pipeline opened beside the live stream's. The build
+  this bullet ships in closes the second (a held element counts as busy) and
+  reads `currentSrc` back, and wraps the three starts the probe could not see
+  (`play()`, `new Audio`, `setAttribute('src')`), read-only. **Waiting on:** the
+  next freeze's page from it. A live stream that plays through with `hold … while
+  vN is held` in front of it is the second fixed; a `new Audio`/`setAttribute
+  src`/`play() … detached` line before the first's `stall` names the element the
+  hold has to learn; nothing stirring with those in is the engine's own, and the
+  pause/play recovery ships.
 
 Five things about that set are settled and should not be re-derived: **key `5` is
 his, not ours** — the engine's overlay path is the only one that gives him a
diff --git a/src/nui/NuiMseHold.cs b/src/nui/NuiMseHold.cs
index 3873fa4..cf11d42 100644
--- a/src/nui/NuiMseHold.cs
+++ b/src/nui/NuiMseHold.cs
@@ -33,8 +33,11 @@ namespace Overscan
     /// then, so the cost is the time to decode a first frame, not a download.
     ///
     /// The holds are precise about *when*: only while another video is playing, which
-    /// is the one state in which a second pipeline is harmful. An element that is
-    /// readied while nothing plays (the first reel, any single-player site) is untouched.
+    /// is the one state in which a second pipeline is harmful, or while another video
+    /// is itself held, which is the page's one tick between pausing a reel and playing
+    /// the next (the 2026-10-05 live-stream freeze was sourced in that tick). An
+    /// element that is readied while nothing plays and nothing is held (the first
+    /// reel, any single-player site) is untouched.
     /// An element with the <c>autoplay</c> attribute is untouched, because the engine
     /// starts that one without the page ever calling <c>play()</c>, and a held source
     /// would then never be released. A new source set on a held element replaces the
@@ -173,16 +176,29 @@ function st(v) {
 
   /* Another <video> that is playing: paused is false the moment play() is called,
      whether or not a frame has shown yet, which is exactly when a second pipeline
-     starts to matter. */
+     starts to matter. Or another <video> that is held: the page has given it a
+     source while something played and has not played it yet, so it is the one
+     about to play. The 2026-10-05 trail (issue #100) is why the second clause is
+     there: at the swipe from a reel to a live stream TikTok paused the reel, set
+     the reel after the live stream on its spare element, and only then played the
+     live stream. For that one tick nothing was playing, the hold let the source
+     through, the engine built its pipeline a second and a half after the live
+     stream's, and the live stream froze. On 2026-10-03 the same gap was sourced
+     and the engine happened not to build early, and that live stream played.
+     With the held one counted the gap is closed; the chain of holds ends where
+     it always did, at the page playing or re-sourcing them. */
   function busy(v) {
+    var held = null;
     try {
       var vs = document.getElementsByTagName('video');
       for (var i = 0; i < vs.length; i++) {
         var o = vs[i];
-        if (o !== v && !o.paused && !o.ended) { return o; }
+        if (o === v) { continue; }
+        if (!o.paused && !o.ended) { return { el: o, why: 'plays' }; }
+        if (!held) { var s = state.get(o); if (s && isHeld(s)) { held = o; } }
       }
     } catch (e) {}
-    return null;
+    return held ? { el: held, why: 'is held' } : null;
   }
 
   var revoke = URL.revokeObjectURL;
@@ -256,7 +272,7 @@ function take(v, value, isSrc) {
     if (!o) { return false; }
     if (isSrc) { s.src = value; holdingUrl[value] = s; } else { s.obj = value; }
     s.since = Date.now();
-    report('hold ' + name(v) + ' ' + (isSrc ? 'blob' : 'srcObject') + ' while ' + name(o) + ' plays');
+    report('hold ' + name(v) + ' ' + (isSrc ? 'blob' : 'srcObject') + ' while ' + name(o.el) + ' ' + o.why);
     return true;
   }
 
@@ -273,6 +289,23 @@ function take(v, value, isSrc) {
     }
   });
 
+  /* currentSrc is what a player reads once it has stopped trusting src: the
+     engine's own answer, which while a source is held is the empty string.
+     TikTok's `[Preloader_TT] onPreloaderError PlayerError: empty src is invalid`
+     landed three times on the 2026-10-05 trail, each some seconds after a hold,
+     so it reads the held URL back too. */
+  var curDesc = Object.getOwnPropertyDescriptor(ME.prototype, 'currentSrc');
+  if (curDesc && curDesc.get && curDesc.configurable) {
+    Object.defineProperty(ME.prototype, 'currentSrc', {
+      configurable: true,
+      enumerable: curDesc.enumerable,
+      get: function () {
+        try { var s = state.get(this); if (s && s.src !== undefined) { return s.src; } } catch (e) {}
+        return curDesc.get.call(this);
+      }
+    });
+  }
+
   if (objDesc && objDesc.set && objDesc.get) {
     Object.defineProperty(ME.prototype, 'srcObject', {
       configurable: true,
diff --git a/src/nui/NuiMseWatch.cs b/src/nui/NuiMseWatch.cs
index 210d64c..af3fef5 100644
--- a/src/nui/NuiMseWatch.cs
+++ b/src/nui/NuiMseWatch.cs
@@ -490,6 +490,66 @@ function wrapSetter(prop, how) {
     };
   }
 
+  /* --- the three ways a media element starts that the wrappers above never see ---
+
+     The 2026-10-05 trail (build-b019483, the first with the detached and audio
+     lines in) had the same freeze as 2026-10-03 to the second, and at the stall:
+     no `(audio)` line, no `detached` line, `scene: 2 video, 0 audio in the
+     document, 1 detached known, 0 iframes`. Yet the native output had the same
+     audio-only pipeline opening at that second. So the element exists and was
+     started by a call none of the above wraps: `new Audio(url)` (the constructor
+     sets the attribute inside the engine, no setter runs), `setAttribute('src')`
+     on an element outside the document (events reach nothing, and the setter
+     wrap is on the property, not the attribute), or `play()` on an element the
+     probe has never heard of. Each of the three is wrapped here the same way as
+     the rest: the original is called with the same this and arguments, its
+     return goes back, its throw reaches the page. A play() is written down only
+     for an element that is detached, an <audio>, or one this probe has no event
+     from yet; a reel's ordinary play() on an element it has been listening to
+     all along adds nothing a `playing` line does not say. */
+  if (ME && typeof ME.prototype.play === 'function') {
+    var playFn = ME.prototype.play;
+    ME.prototype.play = function () {
+      var r = playFn.apply(this, arguments);
+      try {
+        var v = this, g = tag(v);
+        remember(v);
+        if (!v.isConnected || v.tagName === 'AUDIO' || !g.ev) {
+          report(g.id + ' play() ' + origin(v) + ', ' + (v.isConnected ? onScreen(v) : 'detached'));
+        }
+      } catch (e) {}
+      return r;
+    };
+  }
+
+  if (typeof window.Audio === 'function' && window.Audio.prototype) {
+    var Aud = window.Audio;
+    var Wrapped = function Audio(src) {
+      var a = arguments.length ? new Aud(src) : new Aud();
+      try {
+        remember(a);
+        report(tag(a).id + ' new Audio(' + (arguments.length && src !== undefined && src !== null ? describe(src) : '') + '), detached');
+      } catch (e) {}
+      return a;
+    };
+    Wrapped.prototype = Aud.prototype;
+    window.Audio = Wrapped;
+  }
+
+  var EL = window.Element;
+  if (EL && typeof EL.prototype.setAttribute === 'function') {
+    var setAttr = EL.prototype.setAttribute;
+    EL.prototype.setAttribute = function (n, value) {
+      var r = setAttr.apply(this, arguments);
+      try {
+        if ((this.tagName === 'VIDEO' || this.tagName === 'AUDIO') && String(n).toLowerCase() === 'src') {
+          sourced(this, 'setAttribute src', describe(value));
+        }
+      } catch (e) {}
+      return r;
+    };
+  }
+
   function elements() {
     var out = [];
     try {
@@ -591,11 +651,11 @@ function where() {
 
   /* One line per other element, because a stall line already runs near the
      trail's line length on its own: the document's media elements first, then
-     the detached ones that are known, four at most, and the scene line last. */
+     the detached ones that are known, six at most, and the scene line last. */
   function others(v) {
     try {
       var vs = elements();
-      for (var i = 0, n = 0; i < vs.length && n < 4; i++) {
+      for (var i = 0, n = 0; i < vs.length && n < 6; i++) {
         var o = vs[i];
         if (o === v) { continue; }
         n++;
@@ -605,7 +665,7 @@ function others(v) {
                (o.isConnected ? onScreen(o) : 'detached') +
                ', last ' + (g.ev ? g.ev + ' ' + ago(g.at) : 'no event seen'));
       }
-      if (vs.length > 5) { report('with ' + (vs.length - 5) + ' more not listed'); }
+      if (vs.length > 7) { report('with ' + (vs.length - 7) + ' more not listed'); }
     } catch (e) {}
     scene();
   }
diff --git a/tools/msehold/build-page.py b/tools/msehold/build-page.py
index a8e2823..fe55ae8 100644
--- a/tools/msehold/build-page.py
+++ b/tools/msehold/build-page.py
@@ -73,6 +73,12 @@ def script():
 b.src = B.url;
 if (b.src !== B.url) { fail('held element does not read its src back: ' + b.src); }
 if (b.getAttribute('src') !== B.url) { fail('held element does not read its src attribute back'); }
+if (b.currentSrc !== B.url) { fail('held element does not read its currentSrc back: ' + JSON.stringify(b.currentSrc)); }
+
+/* Q: held while A plays and never played by the page, so that at phase 3, with
+   nothing playing any more, it is the held element the gap rule keys on. */
+var q = video('q'), Q = source();
+q.src = Q.url;
 
 /* C: autoplay. The engine starts this one itself, so it must not be held. */
 var c = video('c'), C = source();
@@ -128,8 +134,25 @@ def script():
   phase3.B = B.opened; phase3.E = E.opened; phase3.F = F.opened; phase3.G = G.opened;
   phase3.H1 = H1.opened; phase3.H2 = H2.opened; phase3.sLoad = sLoad;
 
-  /* D: with nothing else playing, a source set on a paused element is untouched. */
   a.pause(); b.pause(); f.pause(); g.pause(); h.pause(); e.pause(); if (stream) { s.pause(); }
+
+  /* R: the gap. Nothing plays, but Q is still held, so a source set now is the
+     reel after the one about to play (TikTok's tick between pausing a reel and
+     playing the live stream, 2026-10-05) and must be held too. */
+  phase3.Qopened = Q.opened;
+  var r = video('r'), R = source();
+  r.src = R.url;
+  phase3.Rearly = R.opened;
+  window.R = R;
+  /* The page then takes Q's source away and plays R: R opens, and once R is
+     paused again nothing is playing and nothing is held. */
+  q.removeAttribute('src');
+  r.play();
+  r.pause();
+  window.Q = Q;
+
+  /* D: with nothing else playing and nothing held, a source set on a paused
+     element is untouched. */
   var d = video('d'), D = source();
   d.src = D.url;
   window.D = D;
@@ -172,7 +195,12 @@ def script():
   if (stream && phase3.sLoad < 1) { fail('srcObject element did not start loading after play()'); }
   if (has(/FAILED/)) { fail('a release failed'); }
 
-  if (!window.D.opened) { fail('d was held with nothing playing'); }
+  if (phase3.Qopened) { fail('q opened although the page never played it'); }
+  if (phase3.Rearly) { fail('r opened at once: a source set while another element is held was not held'); }
+  if (!has(/^hold v\\d blob while v\\d is held$/)) { fail('the gap hold not reported with its reason'); }
+  if (!window.R.opened) { fail('r did not open after play()'); }
+  if (window.Q.opened) { fail('q opened after its source was removed'); }
+  if (!window.D.opened) { fail('d was held with nothing playing and nothing held'); }
   if (!window.L.opened) { fail('with nothing held, a source revoked a tick after the set did not open: F tests the wrong thing'); }
   info.push('control: chromium opens a source revoked right after the set, nothing held: ' + (window.K.opened ? 'yes' : 'no'));
 
diff --git a/tools/msehold/run.sh b/tools/msehold/run.sh
index 2396454..17d8b71 100755
--- a/tools/msehold/run.sh
+++ b/tools/msehold/run.sh
@@ -13,9 +13,11 @@
 #
 # It is the one script we inject that changes how a page loads video, so the
 # harness holds it to the contract and to nothing else: held while another video
-# plays, applied on play(), the source read back as if set meanwhile, untouched
-# when nothing plays, untouched on autoplay, dropped when the page takes the
-# source away, and a revoke of a held URL surviving to the release. Every case
+# plays or is itself held (the tick between pausing one reel and playing the next,
+# where the 2026-10-05 live-stream freeze was sourced), applied on play(), the
+# source read back as if set meanwhile (src, the attribute, currentSrc), untouched
+# when nothing plays and nothing is held, untouched on autoplay, dropped when the
+# page takes the source away, and a revoke of a held URL surviving to the release. Every case
 # is a real MediaSource on a real element, and "opened" means chromium fired
 # sourceopen, which it only does once the engine has the element's source.
 #
diff --git a/tools/msewatch/build-page.py b/tools/msewatch/build-page.py
index 04362b8..56eb241 100644
--- a/tools/msewatch/build-page.py
+++ b/tools/msewatch/build-page.py
@@ -113,6 +113,35 @@ def script():
   if (e.name !== 'TypeError') { fail('srcObject threw ' + e.name + ', not TypeError'); }
 }
 
+/* The three starts the 2026-10-05 trail showed the probe could not see. An
+   element whose source arrives through setAttribute while it is outside the
+   document: the property setter never runs, so the attribute wrap is the one line
+   it leaves, and the attribute and the property must both read back. */
+var attr = document.createElement('video');
+attr.setAttribute('src', 'https://example.invalid/attr/reel.mp4');
+if (attr.getAttribute('src') !== 'https://example.invalid/attr/reel.mp4') { fail('setAttribute wrap did not reach the attribute'); }
+if (attr.src !== 'https://example.invalid/attr/reel.mp4') { fail('after setAttribute, src does not read back: ' + attr.src); }
+
+/* new Audio(url): the constructor sets the source inside the engine, no setter, no
+   setAttribute, nothing in the document. It must still make the engine's own
+   element, with and without an argument. */
+var ctor = new Audio('https://example.invalid/ctor/sound.mp3');
+if (!(ctor instanceof HTMLAudioElement)) { fail('new Audio(url) no longer makes an HTMLAudioElement'); }
+if (Audio.prototype !== HTMLAudioElement.prototype) { fail('Audio.prototype changed'); }
+if (ctor.src !== 'https://example.invalid/ctor/sound.mp3') { fail('new Audio(url) lost its src: ' + ctor.src); }
+var bare = new Audio();
+if (!(bare instanceof HTMLAudioElement) || bare.getAttribute('src') !== null) { fail('new Audio() with no argument changed'); }
+
+/* play() on a detached element, the one call even a new Audio has to make. The
+   promise is the engine's own and rejects on the engine's terms (no source it
+   can load); the wrap must hand it back untouched. */
+var pr = det.play();
+if (!pr || typeof pr.then !== 'function') { fail('play() no longer returns a promise'); }
+pr.catch(function(){});
+var pr2 = ctor.play();
+if (!pr2 || typeof pr2.then !== 'function') { fail('play() on a new Audio no longer returns a promise'); }
+pr2.catch(function(){});
+
 /* Two frames, one ours and one not: the scene line has to tell them apart. */
 var same = document.createElement('iframe');
 same.src = 'about:blank';
@@ -216,7 +245,16 @@ def script():
   if (has(/srcObject/)) { fail('a refused srcObject left a line'); }
   if (!has(/^with v\\d paused rs\\d ns\\d url example\\.invalid\\/detached, detached, last no event seen$/)) { fail('stall does not list the detached element'); }
   if (!has(/^with v\\d \\(audio\\) paused rs\\d ns\\d url example\\.invalid\\/audio, /)) { fail('stall does not list the audio element'); }
-  if (!has(/^scene: 3 video, 1 audio in the document, 1 detached known, 2 iframes \\(1 not ours\\)$/)) { fail('scene line wrong or missing: ' + mse.filter(function(l){ return /^scene/.test(l); })); }
+  if (!has(/^v\\d+ setAttribute src url example\\.invalid\\/attr, detached$/)) { fail('setAttribute src on a detached element not reported'); }
+  if (!has(/^v\\d+ \\(audio\\) new Audio\\(url example\\.invalid\\/ctor\\), detached$/)) { fail('new Audio(url) not reported'); }
+  if (!has(/^v\\d+ \\(audio\\) new Audio\\(\\), detached$/)) { fail('new Audio() not reported'); }
+  if (!has(/^v\\d+ play\\(\\) url example\\.invalid\\/detached, detached$/)) { fail('play() on a detached element not reported'); }
+  if (!has(/^v\\d+ \\(audio\\) play\\(\\) url example\\.invalid\\/ctor, detached$/)) { fail('play() on a new Audio not reported'); }
+  if (mse.filter(function(l){ return /^v\\d+ (\\(audio\\) )?play\\(\\)/.test(l); }).length !== 2) { fail('play() reported other than for the two detached elements: ' + mse.filter(function(l){ return /play\\(\\)/.test(l); })); }
+  if (!has(/^with v\\d+ paused rs\\d ns\\d url example\\.invalid\\/attr, detached, /)) { fail('stall does not list the setAttribute element'); }
+  if (!has(/^with v\\d+ \\(audio\\) paused rs\\d ns\\d url example\\.invalid\\/ctor, detached, /)) { fail('stall does not list the new Audio element'); }
+  if (!has(/^with 1 more not listed$/)) { fail('the seventh other element was not counted as not listed'); }
+  if (!has(/^scene: 3 video, 1 audio in the document, 4 detached known, 2 iframes \\(1 not ours\\)$/)) { fail('scene line wrong or missing: ' + mse.filter(function(l){ return /^scene/.test(l); })); }
   if (mse.filter(function(l){ return /^scene/.test(l); }).length !== 1) { fail('scene reported other than once with the one stall'); }
   if (has(/^stall/) && mse.filter(function(l){ return /^stall/.test(l); }).length !== 1) { fail('one stall reported more than once'); }
 
diff --git a/tools/msewatch/run.sh b/tools/msewatch/run.sh
index f6f5f9b..2728094 100755
--- a/tools/msewatch/run.sh
+++ b/tools/msewatch/run.sh
@@ -21,7 +21,12 @@
 # <audio> element, to writing down a src or load() on a media element that is
 # not in the document and listing it at a stall, to a refused srcObject throwing
 # the engine's own error and leaving no line, and to the scene line telling a
-# frame of ours from another origin's.
+# frame of ours from another origin's. Since the 2026-10-05 trail (that freeze
+# again, with all of it in and nothing stirring) it also holds the wraps of the
+# three starts none of that sees — play() on a detached or audio element,
+# new Audio(url), setAttribute('src') outside the document — to leaving their
+# line, handing the original's return and promise back, and the elements being
+# listed at the stall.
 #
 # The script is lifted out of src/nui/NuiMseWatch.cs rather than copied, for the
 # same reason as tools/msewatch: a harness that tests its own copy tests nothing.