Emby clients can enter uncontrolled request loops without retry backoff

[peter2020 4]

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

[Luke 42756]

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

How to Report a Problem

Thanks!

 

[peter2020 4]

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 42756]

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

[peter2020 4]

I have now analyzed a larger set of access-log data related to the repeated item-detail requests.

In this particular dataset, the uncontrolled loop does not consist of image requests. All identified loop requests target the following endpoint pattern:

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

I inspected several of the item IDs responsible for most of these requests. Every inspected item is a Live TV channel (Type: TvChannel). 
The response contains the current EPG entry in the nested CurrentProgram object, including the programme name, start time, end time and associated image information.

Therefore, in these incidents, the repeated requests are specifically Live TV channel metadata/current-program requests rather than image downloads or media-segment requests.

The behavior is not limited to one channel or one client platform:

- The same channel item was repeatedly requested by multiple independent users, IP addresses and client types.
- Individual users also entered the same loop with several different channel item IDs.
- Affected viewer clients include Samsung Tizen, LG webOS, Amazon Fire TV WebView and an embedded Apple WebKit client.

The request rates remain stable for extended periods and appear to follow fixed client-side intervals. 
Depending on the affected client, I observed approximately one, two or almost five identical requests per second. 
Individual incidents continued for several hours and generated tens of thousands of requests for a single channel item. 
Successful HTTP 200 responses did not stop the repeated requests.

This appears to be more than a minor or cosmetic client issue. A single affected client can generate a substantial amount of unnecessary traffic and request-processing work. 
When several clients are affected, the combined volume can create significant avoidable load, consume server and network resources, and also waste CPU and network resources on the client devices. 
Since the behavior affects normal Live TV usage across several client platforms, I believe it should be treated as a potentially significant reliability and resource-consumption issue.

Based on this additional data, my current hypothesis is that there is a client-side Live TV channel/EPG refresh loop. 
A client appears to repeatedly request the currently selected channel item in order to refresh its CurrentProgram information. 
In the affected state, the refresh timer may be registered multiple times, may run at an incorrect interval, or may not be cancelled correctly.

The fact that similar behavior occurs across several client platforms may indicate shared Live TV, polling, request-scheduling or state-management logic. 
The stable request rates and the fact that successful responses do not terminate the loop make an ordinary transient network retry unlikely.

This does not replace the separate live.m3u8 retry cases described earlier. 
It is additional evidence specifically related to the /Users/{UserId}/Items/{ItemId} Live TV metadata loop.

Could the Emby team please check which client component schedules repeated refreshes of the currently playing Live TV channel item and whether that component or logic is shared across these clients?

[peter2020 4]

One additional concern is that these repeated item-detail requests do not appear to be recorded in the normal Emby server log, at least at the default logging level.

This may make the problem difficult to detect. An administrator might only notice increased server load, network traffic or an unusually high number of requests without being able to identify the endpoint responsible. It is therefore possible that the issue is more widespread but has remained unnoticed on servers that do not retain reverse-proxy access logs.

I would be interested to know whether other Emby server administrators can find similar patterns in their reverse-proxy access logs.

If you are running Emby behind nginx, Traefik, Apache, Caddy or another reverse proxy, please check for repeated requests matching this pattern:

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

The pattern I am seeing has the following characteristics:

The item is a Live TV channel (Type: TvChannel).

The response contains the current EPG programme in CurrentProgram.

The same user and client request the same channel item repeatedly.

Requests occur at a stable frequency of approximately one, two or sometimes almost five requests per second.

The behavior can continue for minutes or hours.

Successful HTTP 200 responses do not stop the repeated requests.

The same behavior can occur with different channel item IDs.

Affected clients in my data include Samsung Tizen, LG webOS, Amazon Fire TV WebView and an embedded Apple WebKit client.

When checking your logs, useful information would include:

Emby client and version

Device/platform

Anonymized endpoint pattern

Number of requests

Duration of the repeated activity

Approximate requests per second

HTTP response status codes

Whether the same user or client exhibits the behavior with multiple Live TV channels

Please make sure to remove user IDs, access tokens, API keys, IP addresses and channel names before posting any log extracts.

A simplified example of the suspicious pattern would look like this:

12:00:00 GET /emby/Users/USER_ID/Items/ITEM_ID 200

12:00:00 GET /emby/Users/USER_ID/Items/ITEM_ID 200

12:00:01 GET /emby/Users/USER_ID/Items/ITEM_ID 200

12:00:01 GET /emby/Users/USER_ID/Items/ITEM_ID 200

12:00:02 GET /emby/Users/USER_ID/Items/ITEM_ID 200

If other administrators can confirm the same pattern, it would help determine whether this is a broader cross-client Live TV/EPG issue rather than an isolated installation-specific problem.

Could the Emby team also confirm whether requests to this endpoint can be included in debug logging or whether there is another recommended way to trace which client component is scheduling them?

[Luke 42756]

HI, when you enable debug logging then all requests will appear in the server log.