Feature description:
This request is for Symfonium when used with Subsonic-compatible media providers such as Navidrome.
In VPS-based server environments with reverse proxies and CDNs (e.g. nginx, Cloudflare),
Symfonium currently relies on timeOffset-based stream regeneration for seeking.
An optional mode where Symfonium relies on standard HTTP Range requests and
server-provided Content-Range / Content-Length would improve compatibility
with such environments, while keeping the current behavior unchanged by default.
Problem solved:
When using Symfonium with a Subsonic-compatible server behind a proxy or cache layer,
timeOffset-based stream regeneration produces full 200 OK responses for different seek positions.
These regenerated streams cannot be safely reused or cached by proxies,
which leads to incorrect playback after seeking
(e.g. wrong audio position, restart, or corrupted playback).
Other Subsonic clients in the same environment work correctly
by relying on HTTP Range-based server responses.
Brought benefits:
This improves Symfonium compatibility with modern server deployments,
including VPS hosting, reverse proxies, and CDNs.
It allows stable seeking and playback in environments where caching
and stream reuse are required, without impacting users who prefer
the current client-controlled behavior.
The feature would benefit users running server-based music libraries,
not only local NAS setups.
Other application solutions:
In the same Navidrome server environment (VPS with nginx reverse proxy and CDN),
other Subsonic clients, including iOS applications, work correctly.
They rely on standard HTTP Range requests and trust server-provided
Content-Range and Content-Length headers for seeking and playback.
These clients do not use timeOffset-based stream regeneration and therefore
remain compatible with proxy and cache layers without playback issues.
Additional description and context:
Symfonium’s timeOffset-based seeking causes the server to generate a new full
200 OK stream for each seek position.
While this works in direct NAS or local connections, it creates conflicts in
VPS-based environments with reverse proxies or CDNs, where stream reuse or
caching may occur, leading to incorrect playback positions or stream errors.
This request does not aim to replace the current behavior, but to provide an
optional alternative that allows server-controlled seeking when needed.
Screenshots / Mockup: