Root Cause (User-Report): bei Part 1/6 Multi-Part-Download mit 869 MB
schon geladen, blieb der Bar auf einer fixen Position weit links — sah
aus als ob ein paar % erreicht waeren obwohl viel mehr lief.
Drei Probleme die das aus 5.0.1-5.0.11 noch ueberlebt haben:
1. downloadVODPart Path A (1-Sek-Heartbeat) emittierte progress=-1
wenn HLS kein known total hat. UI flippte zwischen 'determinate
bei letztem streamlink-%' und 'indeterminate-Animation' — User
sah einen 35%-Bar der zwischen Streamlink-%-Updates kurz aufpoppt.
2. Part-based-Split (download_mode='parts', langes VOD in N Stunden-
Parts) hat downloadVODPart's onProgress UNGEWRAPPT an die UI
gegeben. Bar zeigte 'X% von Part i' statt 'gewichtete overall %'.
Bei Part-Wechsel sprang er von 100% zurueck auf 0%. Bei Part 1
mit 50% Stream-Progress zeigte der Bar 50% obwohl overall erst
bei 8.3% (1 von 6 Parts halb fertig).
3. Full-VOD-Download (kein --hls-duration) hatte kein expected total
fuer den bytes-Estimate -> blieb in indeterminate-Mode.
Fixes:
- downloadVODPart bekommt optionalen Parameter.
Path A schaetzt jetzt progress aus downloadedBytes / (duration *
~625 KB/s, Twitch ~5 Mbit/s Schaetzung), gecappt bei 95%. Wenn
streamlink-stdout-% rauskommt, override mit dem (genauer). Nur
noch progress=-1 wenn weder bytes noch streamlink-% verfuegbar.
- Part-based-Split (downloadVodWithStrategy) wrappt onProgress jetzt
mit einem Aggregator: pro Part den max-bekannten %-Wert merken,
overallProgress = avg(allParts). Bei Part-Done aus dem Loop
partProgresses[i] = 100 setzen. Bar steigt monoton von 0% auf
100% ueber alle Parts.
- Full-VOD-Download passt totalDuration als expectedTotalSec an
downloadVODPart, sodass auch hier der bytes-Estimate greift.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7bc7ef84a2