Sulkta-Coop/torttube
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
torttube/docs/upstream.md
Kayos 0a289fea3a 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.
2026-05-23 11:46:56 -07:00

4.5 KiB
Raw Blame History

Upstream contributions log

One row per PR/issue we file. Outcomes recorded honestly — merged, closed, abandoned, whatever happened.

Active

(none yet — opens with M1 development)

Filed

Date Project PR/Issue Title Status Outcome
none yet

Investigation notes (not yet a PR — to be evaluated)

  • inputstream.adaptive — file:// not supported by libcurl downloader (kodi addon, xbmc/inputstream.adaptive on github) 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. 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 says "this is a known issue", but the app HARD-exits rather than silently dropping one of the dialogs. Look up the upstream tracker before filing.

Watching (not ours, but relevant to torttube)

Project PR/Issue Title Why we care
rustypipe PR #77 "Some fixes" (Schmiddiii) Targeted fixes for YouTube changes ~2026-05-21: video metadata parsing (channel-tag removal) + duration parsing (thumbnail overlay field renames). +15/-11 across 2 files. Stalled in CI-needs-approval. We've independently verified rustypipe-0.11.4 (which predates this PR) still works for player(), search(), and channel_videos() against current YouTube as of 2026-05-23 — Rick Astley video, LTT search returning 19 results, LTT channel browse returning 30 videos. Suggests the breaks PR #77 targets are in code paths we don't exercise. TODO: comment on the PR with this test data + offer to mirror to GitHub if codeberg CI stays blocked. Gated on creating a Sulkta-Coop codeberg account.
NPE #1339 n-parameter deobfuscation broken Core to playback. Fix here = fix in our Tier-1.
NPE #1444 Distinguish unavailable vs unextractable Clean typed-error PR target.
NPE #1360 Refactor link handlers "help wanted" label.
NPE #1357 JDoc checks in PR pipeline "good first issue" — smallest credible first PR.

Posture

  • Every sidecar bug we trace ends with one question: is the root cause in rustypipe / NPE / yt-dlp? If yes, fix it there first; pull the fix into our sidecar via dep bump or backport.
  • We are not pretending to be on the rustypipe / NPE / yt-dlp maintainer level. We're a downstream consumer that does its share.
  • A merged PR > a forked patch. A fork is the last resort, not the first move.