M7 — DASH partial: MPD serves OK, segment alignment still WIP

Big strides today:
- Sidecar resolve_dash op works (verified live on Pi)
- MPD builder generates valid MPEG-DASH on-demand manifest with
  H.264 720p/1080p video reps + best AAC audio rep
- ThreadingHTTPServer serves the MPD over the LAN IP (not 127.0.0.1
  — curl in Kodi 20's inputstream.adaptive can't open that)
- inputstream.adaptive PARSES our manifest cleanly: 'Successfully
  parsed manifest file (Periods: 1, Streams in first period: 2)'
- Segment GETs work once we set stream_headers with User-Agent
  + Origin + Referer (otherwise googlevideo 403s the audio segments)

Remaining issue:
- Audio drifts -25s → -44s behind video within seconds of playback
  start. inputstream.adaptive needs explicit SegmentTimeline timing
  derived from each rep's sidx box to stay aligned. Plugin.video.youtube
  does this; we'd need to fetch+parse sidx ourselves or fork their
  MPD-builder. Documented as M7-blocking + upstream PR candidate.

Default remains the stable yt-dlp progressive 360p path. DASH is
behind dash_enabled setting OR a dash.on marker file in addon_data.
Toggle on via:
  ssh <kodi> 'touch /storage/.kodi/userdata/addon_data/plugin.video.torttube/dash.on'
Toggle off:
  ssh <kodi> 'rm /storage/.kodi/userdata/addon_data/plugin.video.torttube/dash.on'

Addon v0.0.10. docs/upstream.md has the full segment-timing analysis.

docs/upstream.md

@@ -19,10 +19,27 @@ _(none yet — opens with M1 development)_
   ([kodi addon, xbmc/inputstream.adaptive on github](https://github.com/xbmc/inputstream.adaptive))
   Hit during torttube M7 DASH work 2026-05-23. Loading an MPD from a local
   filesystem path via `file:///storage/.kodi/temp/torttube/<id>.mpd` fails
-  with `CURLOpen returned an error, download failed`. Common workaround
-  is a localhost HTTP server (plugin.video.youtube does this). Worth
-  filing an enhancement request to either accept `file://` or document
-  the recommended pattern.
+  with `CURLOpen returned an error, download failed`. **Workaround
+  confirmed**: bind a localhost ThreadingHTTPServer on the LAN IP (not
+  127.0.0.1 — that also fails in some configs) and pass `http://<lan-ip>:<port>`
+  to setResolvedUrl. plugin.video.youtube uses this pattern via a long-lived
+  service addon. Worth filing an enhancement to either accept `file://` or
+  document the LAN-IP HTTP-server pattern in the inputstream.adaptive docs.
+- **DASH segment timing for googlevideo SegmentBase URLs** — Hit 2026-05-23.
+  My MPD with one Representation per video/audio (using SegmentBase with
+  indexRange to the sidx box of the static MP4) parses cleanly and segments
+  fetch correctly once the `User-Agent=Mozilla/...&Origin=https://www.youtube.com&Referer=https://www.youtube.com/`
+  headers are set via `inputstream.adaptive.stream_headers`. BUT audio drifts
+  badly behind video (-25s growing to -44s within seconds of playback start).
+  Hypothesis: inputstream.adaptive needs explicit per-segment timing (via
+  `<SegmentTimeline><S t= d= />` entries) or `presentationTimeOffset` to
+  align separated audio + video streams correctly. plugin.video.youtube
+  derives these by parsing the sidx box of each representation. Possible
+  upstream PRs: (a) inputstream.adaptive should auto-derive segment timing
+  from sidx when SegmentBase + indexRange is present, OR (b) document the
+  requirement for SegmentTimeline on separated A/V. For torttube we'll need
+  to either parse sidx ourselves (extra HTTP HEAD + binary parse) or fork
+  plugin.video.youtube's MPD-builder.
 - **Kodi — "Logic error due to two concurrent busydialogs" fatal**
   Reproduced during rapid back-to-back `Player.Open` calls while a
   previous play's BusyDialog was still dismissing. Log message itself