All Activity

But am I right about changes being required on both sides?

Hi, yes this question has come up before and is possible for future updates. Thanks.

That explanation was shared 3 days ago in a direct quote from trakt devs. Emby needs to update the plugin. "It works on my machine" and "we'll have to keep an eye on it" are not acceptable responses at this point.

Hi there guys, I am having some issues with a specific title. Transformers One (4K). What I see: I play the movie, after a few seconds it stops the playback and buffers and then resumes. This is done on repeat. The "Stats for nerds" is saying that it is reducing the bitrate due the quality. Playback without transcoding works fine. Usually I do not have challenges with playback but at least on this title i am. My GFX seems to be detected properly, so I am assuming the issues is something else. Could you guys look into my logs and let me know if there is something I should be doing differently? I believe there should be several instances of me trying to doing playback of it here, and I can se at 15:58 at least a playback that had some error. Thanks a lot for any help embyserver.txt ffmpeg-transcode-58497fea-b614-4dea-b5f9-801dca0b0b92_1.txt

sorry for bringing this up again but does Emby on ATV nowadays support DV profile 5 and 8 playback? thanks

Have you tried the latest beta of the AndroidTV app version 2.1.51 like ebr suggested? If the problem persists then provide logs as requested Also, try the standard Android app and compare to see if that works.

I couldn't find any info on this, but it would be great to have an option to toggle display of missing movies within a collection.. for example if there is a collection of 5 movies, but I only have 4 of them, we could see maybe a highlighted or greyed out tile for the missing movie?

Any news on this, I am having the same issue, I have 3 nvidia shield and it is only the 2017 nvidia shield That is affected. Emby runs in docker (Synology) and the Emby client has updated only on the 2017 model. Why would it be pushed only to this model ?? Eac3 does not work and must be converted to DD to get audio. Subtitles imbedded in mkv does not show either And some settings changed on it's own in the client too. Quick question, I am running the "Emby for android" client, should I be running the "Emby" client instead?? I just wonder because "Emby for android" is older but better/easier to use, vs the newer Emby client.

I am aware of an issue where changing the contents of an image/photo file does not get reflected in the collage file for a library - I know this happens for a photos library and it may be the same issue here for media image files - if the image file content was changed. With regards to the other issue with the 2nd and 4th poster in the collage, I probably need to have a copy of the database and details of the library and media files involved and ones that were removed before and which had custom images The database copy might not be sufficient for me to investigate. How big are these folders: cache/images metadata/library Does this issue of the collage image not getting updated only happens with libraries with custom media ? Does it happen if a library did not have any custom images and you removed media items that are in the collage and did a refresh?

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.