All Activity

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.

Thats what I have been saying. "Emby's built-in Trakt plugin uses the old, legacy PIN flow". Thanks for confirming my suspicions

Trakt support reports: Apparently, the problem lies in the fact that Emby is still using an outdated authentication method that has not been supported for some time. Since PIN codes are no longer required, a change needs to be made so that users can log in again.

I did a clean install of W11 over the weekend and since then I'm unable to sign in to Emby using Firefox. When I go to the Emby page and click Sign In, it takes me to a page that says "Welcome to Emby", I click next and it goes to "Let's Get Set Up". I can't seem to do anything and just go round in circles. I can enter Emby using the IP (only using local network) but nothing on Firefox, network is set to private too. I'm sure I've had this problem before but can't remember how I resolved it. Here's the latest log so hope someone can help me out. Thanks.embyserver.txt

My son has a Steam Deck, and this forum post helped him tremendously with this bug. Thank you for sharing it!

Some update(s) on the IOS app ?

Here you go embyserver-63920361430.txt

That doesn't prove that the fallbacks are working properly. What if they're being changed on purpose?

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

Not sure what you mean? it would behave currently as what emby does, does it override already existing data?

What if some other people have that node filled in with the correct ID?

hi this is the file embyserver.txt

Let's see if 4.10 solves it soon. 4.10.0.20-beta came out recently. Release notes don't mention changes on transcoding, but 99% of times the release notes don't contain all changes, so who knows (shrug)

Emby needs an ad campaign around this. "Is your Plex down again and you can't get in? Then Emby is the pill for you!"

For those wanting a good laugh.

New version up (v1.0.6.0) in the catalog. Added support for TheIntroDB.

> I think we should probably change it, but then we'll have to deal with those that might be impacted by the change. Honestly, the only impact of this change is that instead of filling incorrect id in imdb, it will instead fill the tmdb GUID i really dont see any downside, nobody want incorrect information, as this also breaks the index imdb link in emby itself

Basically, he's wanting you to provide the server and transcode logs for the period you noticed the error. The media info for the video may help also.

@phoeskyI think what's happening is that it's not an issue of outdated cover images, but rather you have content still in your database that should have been deleted some time ago. Unfortunately this might be caused by defects in older Emby Server versions and would require a fresh database to resolve. @sa2000can help you confirm that and give you some next steps. Thanks.

HI, we'll have the new ffmpeg build on the server beta channel very soon, so stay tuned for that. Thanks.

is it clear?

ok can you please attach the emby server log from when that happened? Thanks.

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

Hi everyone, I'm having an issue with my Emby setup and my Samsung Smart TV, and I hope someone here can point me in the right direction. The Problem: The official Emby app on my Samsung TV loads perfectly. I can browse my entire library, see all the movie posters, metadata, and menus without any lag. However, when I hit "Play" on a movie, the video simply doesn't start. It just hangs on a black screen with an infinite loading spinner. My Setup: Emby Server OS: Cloud VPS Hetzner Client: Samsung Smart TV (Tizen) - Official Emby App 2.2.8 (because want to mountain the official one) Media Type: Movies (mostly MKV/MP4 files) What I've noticed: The network connection is definitely fine since the UI and all images load instantly. I suspect this might be an issue with the Samsung internal video player struggling with certain codecs, or a Direct Play vs. Transcoding failure. If I play the same movie on my PC or smartphone via Emby, it works perfectly. Has anyone experienced this specific issue with Tizen OS? Are there any specific playback settings in the TV app (like forcing/disabling Direct Play) or server-side tweaks I should try to bypass the Samsung player limitations? I can provide the server logs if needed. Thanks in advance for any help!

Hi, I'm seeing exactly the same behaviour described in this thread on my Synology DS918+ (Intel J3455), but I spent some time trying to isolate the problem and I may have some additional information that could help. Environment Emby Server 4.9.5.0 Synology DS918+ Intel J3455 (Apollo Lake) DSM 7.2.x Hardware acceleration enabled (Quick Sync + VAAPI) Tested with: Emby Web (Chrome on Windows) Emby Windows app The problem Whenever an HDR video is transcoded using hardware acceleration, the image becomes washed out, as if HDR is being displayed as SDR without proper tone mapping. If I disable hardware acceleration and let FFmpeg perform software transcoding, the colours are correct. Tests performed I tried several different files and configurations to narrow it down. HDR10 4K Hardware transcoding → washed out colours. Software transcoding → colours are correct. Dolby Vision Profile 8.1 (HDR10 compatible) Hardware transcoding → washed out colours. Software transcoding → colours are correct. HDR10 1080p Hardware transcoding → washed out colours. I also tested: Quick Sync only (VAAPI disabled) Quick Sync + VAAPI Different remote streaming bitrates Different transcoding resolutions Emby Web and Emby Windows The behaviour is always the same. What I found in the logs The interesting part is that Emby reports: Tone Mapping would be desired, but hardware tone mapping is disabled but immediately afterwards the processing plan says: ToneMapping (when possible) CanDoInHW = True WillDoInHW = True When I inspect the generated FFmpeg command, I only see: HEVC_QSV → vpp_qsv (resize) → vpp_qsv (P010 → NV12) → H264_QSV I cannot find any actual tone mapping filter being inserted (tonemap, tonemap_opencl, zscale, or any explicit BT.2020 → BT.709 colour conversion). So it looks as if the processing plan expects hardware tone mapping to happen, but the generated FFmpeg command never actually performs it. Question Is this expected behaviour on Apollo Lake hardware, or could this be a bug or regression in the current hardware transcoding pipeline? I've attached three different ffmpeg-transcode logs showing the same behaviour: HDR10 4K HDR10 1080p Dolby Vision Profile 8.1 (I also attach a software transconding log for this one) If needed, I can also provide the corresponding embyserver logs. Thanks! 4KHDR-ffmpeg-transcode-ce9e3357-e5fe-4e89-8083-135e1897db1b_1.txt 1080pHDR-ffmpeg-transcode-265e6ece-46b8-4317-bfd4-953bd2d6a758_1.txt 4KDV-Software_deco-ffmpeg-transcode-c8af9373-a1a5-40c3-a4ee-3037e5dd825d_1.txt 4KDV-Hardware_deco-ffmpeg-transcode-d506bd22-4ef2-4fc2-b0d1-0fc352bc8d04_1.txt