Kayos
0a289fea3a
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.
67 lines
4.5 KiB
Markdown
67 lines
4.5 KiB
Markdown
# 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](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`. **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](https://codeberg.org/ThetaDev/rustypipe/pulls/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](https://github.com/TeamNewPipe/NewPipeExtractor/issues/1339) | n-parameter deobfuscation broken | Core to playback. Fix here = fix in our Tier-1. |
|
|
| NPE | [#1444](https://github.com/TeamNewPipe/NewPipeExtractor/issues/1444) | Distinguish unavailable vs unextractable | Clean typed-error PR target. |
|
|
| NPE | [#1360](https://github.com/TeamNewPipe/NewPipeExtractor/issues/1360) | Refactor link handlers | "help wanted" label. |
|
|
| NPE | [#1357](https://github.com/TeamNewPipe/NewPipeExtractor/issues/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.
|