Emby clients can enter uncontrolled request loops without retry backoff

[peter2020 2]

Hi,

I have observed multiple cases where Emby clients entered long-running request loops against different Emby API endpoints.

Although the affected endpoints and clients differ, the behavior appears similar: the client repeatedly sends the same request without an effective delay, backoff or termination condition.

Environment:
- Emby Server version: 4.9.5.0
- Confirmed clients in some of the cases:
  - Emby for Samsung
  - Emby for Android
- The client responsible for some Live TV cases could not be identified from the available logs.

Case 1: Item-detail requests

Affected endpoint:

GET /emby/Users/{UserId}/Items/{ItemId}

Four analyzed log extracts contained approximately 198,000 requests to four individual item-detail URLs.

Observed behavior:
- Bursts continued for up to approximately four hours.
- The same item was requested about once or twice per second.
- Most responses were successful HTTP 200 responses.
- Successful responses did not stop the repeated requests.
- Individual clients generated tens of thousands of requests for the same item.

Case 2: Live TV playlist requests

Affected endpoint:

GET /emby/videos/{ItemId}/live.m3u8

One incident produced:
- Approximately 490,000 requests to the same playlist
- A duration of approximately three and a half hours
- Only HTTP 401 responses
- Peaks of more than 12,000 requests within five minutes
- Up to 43 requests during the same second

Another incident produced:
- Approximately 12,700 requests over four hours
- A mixture of HTTP 200 and HTTP 401 responses
- Peaks of approximately 5,000 requests within five minutes
- Up to 39 requests during the same second

Common behavior

In all cases:
- The same endpoint was requested repeatedly for an extended period.
- There was no effective retry delay or exponential backoff.
- Successful HTTP 200 responses did not always stop the loop.
- HTTP 401 responses could trigger a particularly aggressive retry storm.
- Multiple identical requests sometimes arrived during the same second.
- The behavior continued until the client or session was interrupted.

Expected behavior

- A successful item-detail response should not be requested again every second unless something has changed.
- Live playlist polling should use an appropriate refresh interval.
- After HTTP 401, the client should stop playback, refresh authentication or apply exponential backoff.
- Duplicate or concurrent retries should be limited.
- Repeated failures should eventually terminate the operation and display an error to the user.

Impact

A single affected client can generate tens or hundreds of thousands of unnecessary requests, place significant load on the Emby server, and consume unnecessary resources on the client itself.

Could this behavior originate from a shared retry, polling, request-scheduling, or client-side state/cache handling component used by multiple Emby clients?

Please let me know which server or client debug logs would be helpful for identifying the trigger. I can provide sanitized access-log samples if required.

Edited 47 minutes ago by peter2020
add server version