Kayos
9ed0aae2d0
After hitting the segment-timing wall on our hand-rolled DASH MPD
(audio drifted -25s -> -44s behind video on long content), pivoted to
delegating playback to plugin.video.youtube v7.4.3 which already has
years of sidx-parsed SegmentTimeline + multi-client fallback work.
torttube._play() now:
1. Tries _delegate_to_pv_youtube(yt_id) — sets a resolved URL of
'plugin://plugin.video.youtube/play/?video_id=<id>'. Kodi
chain-resolves to pv.youtube which builds the proper MPD and
hands inputstream.adaptive a correctly-aligned manifest. Default.
2. Falls back to our DASH builder (still in code, gated by
'dash_enabled' setting + dash.on marker) if pv.youtube is absent.
3. Falls through to yt-dlp progressive 360p as the final safety net.
When delegating, we skip our SponsorBlock monitor — pv.youtube has its
own and would double-skip otherwise.
Cobb-verified live on Livingroom Pi: LTT 'Trump Phone' (which crashed
our DASH with audio sync errors growing to -44s) now plays HD with
audio synced. 'Please sign in' message in log is from the tv_unplugged
Innertube client; pv.youtube falls back to a working client
automatically — no user account required.
Settings: prefer_pv_youtube boolean (default true). Addon v0.0.11.
Reference: https://kodi.wiki/view/Add-on:YouTube
5.3 KiB
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 viafile:///storage/.kodi/temp/torttube/<id>.mpdfails withCURLOpen 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 passhttp://<lan-ip>:<port>to setResolvedUrl. plugin.video.youtube uses this pattern via a long-lived service addon. Worth filing an enhancement to either acceptfile://or document the LAN-IP HTTP-server pattern in the inputstream.adaptive docs. -
Architecture resolution: torttube delegates playback to plugin.video.youtube 2026-05-23. After spending an iteration on a native DASH MPD builder + HTTP manifest server, conceded that solving segment-timing alignment correctly (sidx-parse, SegmentTimeline emission, audio-rate detection, init-segment presentationTimeOffset) is multiple-week work. plugin.video.youtube has years of that work already. torttube now does what it's faster at (Rust rustypipe search/browse, SponsorBlock skip with fewer false positives) and hands the video_id to pv.youtube for actual playback. This is the "stand on giants' shoulders" call rather than reinvent. Native DASH code path stays in the addon as a fallback when pv.youtube is absent (or as a testbed for someday revisiting). Reference: https://kodi.wiki/view/Add-on:YouTube
-
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 viainputstream.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) orpresentationTimeOffsetto 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.Opencalls 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.