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 yesterday at 12:17 PM by peter2020
add server version

[Luke 42745]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[peter2020 2]

Server and client

- Emby Server: 4.9.5.0
- Client: Emby for Android 3.5.37
- Device: Amazon Fire TV (Android 7.1.2)
- Content: Live TV, direct stream (MPEG-TS)
- Date: 17 July 2026
- Reported block: approximately 12:05 CEST (10:05 UTC)

Description

During Live TV playback, Emby for Android entered what appears to be a request/retry loop. The client requested the same item endpoint approximately once per second:

GET /emby/Users/USER_ID/Items/ITEM_ID

The sanitized reverse-proxy log contains 238 requests for this endpoint in the supplied extract. The continuous burst runs from 10:00:00 through 10:03:55 UTC (12:00:00 through 12:03:55 CEST). Requests that reached the origin received HTTP 200 with the same response size (mostly 1321 bytes) and normally completed in 1-2 ms.

After this burst, our IDS/security script blocked matching requests as a protective reaction to the unusual request rate. Requests rejected by this security layer do not appear in the origin reverse-proxy or Emby logs. The security block is a consequence of the request loop, not the issue being reported.

At the same time, POST /emby/Sessions/Playing/Progress from the same device continued to reach Emby every approximately ten seconds and returned HTTP 204, including at 12:05:06 CEST. Therefore the Emby session and authentication remained active while the visible problem occurred.

The existing video request remained open until 12:11:00 CEST. The Emby server log then reports "Response completed after client disconnected", followed by Pause and Playing/Stopped from the Android client.

Important logging limitation

The normal Emby server log does not contain the repeated GET /emby/Users/USER_ID/Items/ITEM_ID requests at all. It contains the PlaybackInfo calls and the Playing/Progress calls, but this particular item endpoint is apparently not written at the normal log level. For that reason, the request loop is demonstrated by the attached reverse-proxy access log rather than by the Emby server log.

Expected behavior

The Android client should not continuously request the same item endpoint once per second during normal Live TV playback, and it should not remain in a retry loop until an upstream rate limit is triggered.

Actual behavior

The same item was requested approximately once per second for almost four minutes. The UI/playback appeared blocked at approximately 12:05 CEST. Playstate heartbeats continued successfully, and the client finally disconnected the media request at 12:11 CEST.

Attachments

- 01-reverse-proxy-access-sanitized.log: affected-client requests in chronological order
- 02-emby-server-sanitized.log: playback start, progress around the incident, and disconnect
- 03-log-correlation.txt: timeline and explanation of the different time zones

I would like to know why the Android client repeatedly polls the same /Users/{UserId}/Items/{ItemId} endpoint during playback.

01-reverse-proxy-access-sanitized.log 02-emby-server-sanitized.log 03-log-correlation.txt

[Luke 42745]

Hi, we'll take a look at it. Thanks for reporting.