xRangerDEandClaude Opus 4.7
7bc7ef84a2
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>