Kayos
45e1306bf3
Sidecar resolve_dash op shipped — returns rustypipe's full video_only_streams + audio_streams (16+ representations for NGGYU, from 360p H.264 through 4K AV1). Addon _build_dash_mpd assembles a valid on-demand MPEG-DASH manifest filtered to H.264 ≤1080p + best AAC audio. Two unblocked-by-WIP issues surfaced during integration: - inputstream.adaptive's libcurl can't open file:// URLs (logged in docs/upstream.md as an enhancement-target). - Rapid Player.Open retries can trigger Kodi's 'two concurrent busydialogs' fatal exit; need lifecycle hardening before re-enabling. Pivoted to localhost HTTP-server serving (ThreadingHTTPServer on a port-0 socket, MPD bytes captured in a per-instance handler subclass). Lifecycle: server.shutdown() runs in a finally block after the SponsorBlockMonitor watcher exits. Works in isolation but Kodi crashed under rapid retry conditions — needs more testing. For v0.0.5: DASH path is gated behind TORTTUBE_DASH=1 env var; default falls through to the stable yt-dlp progressive 360p path that's been verified live. M7 milestone added to track the remaining work; PRs to inputstream.adaptive + Kodi candidates logged in docs/upstream.md.
2.6 KiB
2.6 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. Common workaround is a localhost HTTP server (plugin.video.youtube does this). Worth filing an enhancement request to either acceptfile://or document the recommended pattern. - 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" | Open 2026-05-23, unmerged. If maintainer stays quiet we may need to help land it or fork. |
| 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.