fix(player): reduce Windows playback cache memory

[ThePunpun]

Summary

Fixes #555.

• Reduces the Windows embedded player’s forward demuxer cache from 512 MiB to 256 MiB.
• Reduces its backward cache from 256 MiB to 64 MiB.
• Leaves the existing cache duration unchanged so the fix is limited to byte-based memory bounds.
• Keeps the seekable cache enabled for responsive backward seeking.
• Reduces high-bitrate playback memory without changing hardware decoding, playback controls, or UI.

PR type

• Reproducible bug fix
• UI glitch/bug fix
• Behavior bug/regression fix
• Small maintenance only, with no UI or behavior change
• Docs accuracy fix
• Translation/localization only
• Approved larger or directional change

Why

The Windows embedded player allowed up to 768 MiB of demuxer cache. High-bitrate remux playback could therefore raise Nuvio’s memory usage substantially above its loaded Home-screen baseline.

A controlled A/B test using the same application build, hardware, title, source, and two-minute playback duration showed approximately 420 MB lower total peak memory after reducing the byte limits.

The selected limits retain approximately 24–27 seconds of buffered content in the tested high-bitrate stream while preserving responsive seeking. Lower byte limits were intentionally avoided to retain sufficient protection against network variation.

Desktop scope

This change is limited to the Windows embedded native player in player_bridge.cpp.

It does not change:

• macOS or Linux native-player configuration
• Android, Mobile, or TV playback
• external-player behavior
• shared Compose player UI
• player teardown or Home-screen memory behavior

Issue or approval

Fixes #555.

UI / behavior impact

• No UI change
• No behavior change
• UI changed only to fix a documented glitch/bug
• Behavior changed only to fix a documented bug/regression
• UI change has explicit maintainer approval
• Behavior change has explicit maintainer approval

Policy check

• I have read and understood CONTRIBUTING.md.
• This PR is small, focused, and limited to one problem.
• This PR is scoped to the desktop app, desktop packaging, desktop documentation, or shared code required for desktop behavior.
• This PR is not cosmetic-only.
• Any UI change fixes a linked glitch/bug and includes visual proof, or this PR has no UI change.
• Any behavior change fixes a linked bug/regression or has explicit approval, or this PR has no behavior change.
• This PR does not bundle unrelated refactors, cleanups, formatting, or drive-by changes.
• This PR does not add dependencies, architecture changes, migrations, or product-direction changes without explicit approval.
• I listed the testing performed below.

Scope boundaries

• Does not add forced garbage collection, working-set trimming, or manual memory cleanup.
• Does not change the existing player teardown lifecycle.
• Does not attempt to reduce the baseline Compose/JVM memory footprint.
• Does not change Home metadata refresh behavior.
• Does not alter initial playback or rebuffer thresholds.
• Does not change UI, settings, dependencies, or architecture.
• Does not affect external players or non-Windows platforms.

Testing

Tested locally on Windows 11 with an Intel Core i7-10700K and NVIDIA GeForce RTX 2060 SUPER.

A controlled A/B test used the same build, approximately 130 GB remux, remote source, hardware, and two-minute playback duration:

Measurement	Original cache	Reduced cache
Loaded Home baseline	729–731 MB	743 MB
Steady playback	1.59–1.64 GB	1.18–1.21 GB
Playback peak	1.640 GB	1.220 GB

The reduced configuration lowered:

• Total peak process memory by approximately 420 MB, or 26%.
• Playback-specific overhead by approximately 434 MB, or 48%.

The measurement run included a 120-second time limit, but its observed buffer-ahead remained approximately 24–27 seconds. The time limit was therefore not reached, and the final patch leaves cache-secs unchanged.

Also verified:

• Hardware decoding remained active through d3d11va.
• Playback remained stable during the test.
• Seeking remained responsive.
• Buffer-ahead remained approximately 24–27 seconds.
• Exiting playback continued to use the existing teardown path.
• Returning Home reached approximately the loaded Home baseline in the controlled runs.
• .\gradlew.bat :composeApp:desktopTest completed successfully.
• .\gradlew.bat :composeApp:desktopJar completed successfully.
• The Windows native player bridge rebuilt successfully for the measured reduced-cache configuration.

macOS, Linux, Android, and external-player runtime testing was not performed because their implementations are unchanged.

Screenshots / Video

Not a UI change.

Breaking changes

None.

Linked issues

Fixes #555.

[haaihond]

Why reduce the buffer time (seconds) limit? The megabyte limit can keep the buffer in line by itself.