torttube/docs/upstream.md
Kayos 45e1306bf3 DASH HD playback — WIP behind TORTTUBE_DASH=1 + upstream notes
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.
2026-05-23 11:14:56 -07:00

50 lines
2.6 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`. 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.
- **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" | Open 2026-05-23, unmerged. If maintainer stays quiet we may need to help land it or fork. |
| 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.