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 July 16 by peter2020
add server version

[Luke 42768]

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

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

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

[peter2020 4]

Hi,

following your suggestion, I enabled debug logging and captured another occurrence of the repeated item-detail request loop.

I have attached the sanitized Emby server debug log:

embyserver-anonymized.txt

How to locate the relevant requests

Please search the attached log for either:

/Items/446364

or:

/emby/Users/[USER_ID]/Items/

The relevant continuous burst occurred on 23 July 2026 between approximately 14:05:00 and 14:08:53 CEST (12:05:00–12:08:53 UTC).

Scope of this example

The attached debug log documents one specific occurrence involving:

- Emby Server: 4.9.5.0
- Client in this example: Emby for Android 3.5.34
- Platform: Amazon Fire TV / AFTSS, Android 9
- Endpoint:

GET /emby/Users/[USER_ID]/Items/446364

However, this behavior is not limited to Emby for Android or Amazon Fire TV.

I have observed the same repeated item-detail request pattern with multiple independent users and several different client platforms, including:

- iPad / Emby for iOS
- Samsung TV / Tizen
- LG TV / webOS
- Amazon Fire TV
- embedded Apple WebKit-based clients

The attached Android log is therefore only one clearly documented example of a broader cross-client pattern.

Observed behavior

The client repeatedly requested exactly the same item-detail endpoint:

- 231 GET requests during the continuous burst
- Duration: approximately 233 seconds
- Average interval: approximately 1.015 seconds
- Approximately 59–60 requests per minute
- All 231 requests received successful HTTP 200 responses
- Responses normally completed in approximately 1–2 ms

The per-minute request counts during the burst were:

- 14:05: 59 requests
- 14:06: 60 requests
- 14:07: 59 requests
- 14:08: 53 requests before the protective block took effect

The first request of the continuous burst appears at:

14:05:00.193

The last request that reached Emby appears at:

14:08:53.609

Its successful HTTP 200 response appears at:

14:08:53.611

There are also three earlier requests for the same item at approximately 14:01, so the attached log contains 234 GET requests for item 446364 in total.

Please note that every request and its corresponding response are separate lines in the debug log. They should not be counted as two requests.

Protective block

After the number of identical requests became too high, my upstream security/rate-limit rule began rejecting further matching requests before they reached Emby.

This explains why no further requests matching:

/emby/Users/[USER_ID]/Items/

from this client appear in the Emby log after approximately 14:08:53.

The absence of later requests in the server log should therefore not be interpreted as evidence that the client recovered or stopped the loop by itself. The security block was a protective consequence of the repeated requests, not the cause of the behavior.

Conclusion

This debug log confirms one instance in which an Emby client repeatedly requested the same item-detail endpoint approximately once per second, even though every request received a fast and successful HTTP 200 response.

Although the client in this attached example is Emby for Android, the same general behavior has been observed across several unrelated Emby client platforms. It should therefore not be treated as an Android-only issue.

The cross-client occurrence suggests that the cause may be shared Live TV/EPG polling, request scheduling, state management or current-program refresh logic.

Could the Emby team please investigate which component schedules repeated refreshes of the currently selected Live TV channel item, whether this logic is shared across clients, and why the polling timer is not cancelled or reduced after successful responses?

embyserver-anonymized.7z

[peter2020 4]

Hi,

one additional observation from the affected request loops:

The repeated requests appear to consistently use this specific pattern:

GET /emby/Users/{UserId}/Items/{ItemId}?ExcludeFields=VideoChapters%2CVideoMediaSources%2CMediaStreams&...

So far, the uncontrolled loops seem to affect only item-detail requests where ExcludeFields is the first query parameter.
Other requests to the same item endpoint use different query parameters and do not appear to be part of the loop.

This may help narrow down which client-side refresh component is responsible.