LG webOS app cannot sustain ~80 Mbps HTTP streams (4K REMUX stalls) while the Cast receiver and a LAN proxy play the same URL fine

[mattdoescode]

Environment

• TV: LG OLED77C5PUA (webOS 25), Stremio app io.strem.tv from the LG Content Store (bundled streaming server reports v4.20.11)
• Network: TV on gigabit Ethernet (Wi-Fi disabled), 1 Gbps internet
• Stream source: direct HTTPS link from a debrid CDN via the Torrentio addon (no P2P, no transcoding)
• Content: 2160p UHD BluRay REMUX, HEVC Main 10, 81 Mbps average, Dolby Vision, TrueHD Atmos default track, MKV, 76 GB

Problem
Playback of high-bitrate HTTP streams stalls constantly. Measured with the player OSD timestamp against wall clock over 90 to 137 second windows: the movie advances 55 to 88 percent of real time (for example 53 s of playback per 97 s wall clock). Decoding is fine: video keeps advancing between stalls and the Dolby Vision badge shows.

What was ruled out

• CDN and WAN: a PC on the same LAN pulls 292 to 320 Mbps from the exact same URL.
• Audio codec: switching from TrueHD to the DD 5.1 track changes nothing.
• Dolby Vision or container: a 24.5 GB x265 encode of the same disc (DV + TrueHD, MKV, ~25 Mbps) plays at exactly real time (96 s per 97 s). A 30 GB AMZN WEB-DL (DV, ~25 Mbps) also plays at real time.
• Wi-Fi: moving the TV from Wi-Fi to Ethernet improved the ratio from ~70 percent to 80 to 88 percent but did not fix it.
• Streaming server: the debrid link plays direct regardless of the streaming server URL; pointing the app at a LAN Stremio server with proxyStreamsEnabled produced zero connections to it during playback. Routing through the app's own bundled server via behaviorHints.proxyHeaders did not help either (that server proxies at about 39 Mbps on the TV CPU).

Evidence it is the app's HTTP fetching

• The same TV, same file, cast from web.stremio.com in Chrome to the LG Google Cast receiver plays at real time for minutes, so the TV hardware and its network path can do it.
• Serving the same file to the TV app through a LAN read-ahead range proxy (8 MiB chunks, 12 chunks prefetched, on a PC 1 ms away) makes the app play at real time (97 s per 99 s wall clock, proxy serving 80 to 94 Mbps). A synthetic client doing small sequential range reads gets 50 to 65 Mbps from the CDN directly but 166 Mbps through that proxy, which matches the stall ceiling.

So the webOS app's media pipeline appears to issue small sequential range requests with little read-ahead, capping throughput by round-trip latency to the CDN at roughly 50 to 65 Mbps. Anything above that bitrate stalls.

Expected
The app should sustain at least the bitrates the TV hardware and Cast receiver already handle (80 to 100 Mbps) from a remote HTTPS source, for example by requesting larger ranges or buffering further ahead.

Reproduce

1. On an LG webOS TV, open any 4K UHD REMUX (about 80 Mbps) as a direct HTTPS stream from a debrid addon.
2. Show the OSD and note the timestamp; compare with wall clock after 90 seconds.
3. Repeat with a ~25 Mbps encode of the same title: real time. Repeat the REMUX cast from Chrome to the same TV: real time.

Happy to run further tests or capture logs on request.

[mattdoescode]

Closing this from my side after further investigation.

I tried to work around it on the TV itself: I sideloaded a community webOS build with an in-app Node read-ahead range proxy, so the app would fetch through a local buffered proxy instead of straight from the CDN. The same proxy code sustains 235 Mbps on a PC, but on the TV it made playback worse, 63 to 77 percent of real time versus 80 to 88 percent direct. That puts webOS Node's HTTPS throughput at roughly 40 to 55 Mbps, matching the 39 Mbps I measured through the app's own bundled server proxy. So the on-device path is CPU-bound in JavaScript and cannot carry an 81 Mbps stream, which is why I have no fix to propose here.

For anyone hitting the same wall: a read-ahead range proxy on another LAN machine does solve it. With streams pointed at that, the same webOS app plays the 81 Mbps REMUX at real time (97 s of playback per 99 s wall clock).

Closing as I have nothing further to test. Maintainers should feel free to reopen if the native fetch behavior is worth a look, since the Cast receiver on the same TV plays the same file at real time.