Emby endpoint failover should handle TCP-success but HTTP/API-timeout endpoints

Streaming & Network
1

Hi Infuse team,

I would like to report a possible failover issue in Infuse when connecting to an Emby server through either a hostname with multiple IPv4 A records or the newer multi-endpoint setup.

I am intentionally not including the real hostname, IP addresses, or server name publicly. I can share them privately if needed.

Summary

The Emby server is reachable through multiple IPv4 endpoints. Some endpoints may still complete the TCP handshake, but they are temporarily unable to serve application data because of upstream bandwidth/quota exhaustion. Other endpoints remain healthy and can serve the same Emby server normally.

In this situation, Infuse appears to treat the first/primary endpoint as usable as soon as the TCP connection succeeds. It then keeps trying that endpoint and does not fail over to another resolved A record or another configured endpoint, even though the selected endpoint later times out at the HTTP/Emby API layer.

Reproduction steps

  1. Set up an Emby server reachable through a hostname that resolves to multiple IPv4 A records, or configure the same addresses in Infuse’s multi-endpoint feature.
  2. Make endpoint A accept TCP connections on the Emby HTTP port, but have it stall or time out for actual HTTP/Emby API requests due to upstream traffic/quota exhaustion.
  3. Make endpoint B serve the same Emby server normally and return valid Emby API responses.
  4. Add the server in Infuse using the hostname, or configure endpoint A as the primary endpoint and endpoint B as an additional endpoint.
  5. Open the Emby server/library in Infuse.

Actual result

Infuse fails to load or stays stuck when it lands on endpoint A. It appears not to try endpoint B or other healthy A records, because endpoint A passed the TCP-level connection test.

The same issue seems to affect the multi-endpoint feature: if the primary endpoint is TCP-reachable but cannot return valid Emby HTTP/API data, Infuse does not move on to the other configured endpoints.

Expected result

If an endpoint completes the TCP handshake but fails to return a valid HTTP/Emby API response within a reasonable timeout, Infuse should treat that endpoint as unhealthy for the current attempt and fail over to the next configured endpoint or next resolved A record.

The health check should ideally be application-layer aware, for example by requiring a successful response from an Emby API endpoint such as /System/Info/Public, instead of treating TCP reachability alone as success.

Why this matters

For DNS round-robin or multi-endpoint deployments, TCP reachability is not enough to prove that an endpoint can actually serve media or Emby API responses. A TCP-success but HTTP-timeout endpoint can make Infuse fail even while another configured/resolved endpoint is fully working.

Thanks for considering an optimization here.

1 Like