All Activity

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

What exactly in that screenshot are you referring to?

They made a breaking api change. Things are going to happen when you do that.

Something has absolutely has had to change, because up until the past month or so my apps never connected to the local IP. Because the IP reported by the Emby server itself in current streaming sessions shows this has to be the case. And no it's not due to X-Forwaded headers or anything, because that wouldn't match it either. They always utilized the IP associated with the DNS FQDN that I initially input to connect them with. And now they don't. They ignore it. They use the local IP and they're using HTTP vs HTTPs. I've had to resort to blocking via local Firewall So clients cannot access the server directly, and only the reverse proxy and or cloudflare tunnel apps can. That's never had to happen before. And Emby Network settings haven't changed for a couple years at this point. And this also happened on multiple Android apps, across a fire stick, Onn Google TV stock, And Android phone. Two different networks. One network is actually in a completely different subnet across the VPN tunnel, so it couldn't even have seen the local broadcast Discovery mechanism that's in place either Edit: Also as I noted, The local IP address I've always had configured on the network settings page in Emby, it was this FQDN, not an IP. And again that FQDN does not resolve to the local IP/s of the Emby Server.

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?

As I stated in this post, I rolled back to 4.10.0.11 to see if the memory usage spike when manually initiating a library scan first thing in the morning occurs as frequently as it does after updating to Beta 4.10.0.15 and beyond. Four days later, and there have been no memory spikes in that scenario. I'm going to hang back on 4.10.0.11 for another few days. Post 4.10.0.15 I was seeing this issue within 24 to 48hours of restarting Emby since mid-June. The image below shows 4 spikes in memory usage over four days post 4.10.0.15 . Each one of those occurred when a manual library scan was run first thing in the morning after the server had been idle overnight. Only one of them (the first one) lead to an OOM event that shutdown Emby. But all of them resulted in Emby becoming unresponsive for the duration of the scan. I'll post back after installing Beta 4.10.0.20 later later this week and running it for a few days. Hopefully there will be no memory usage spikes...fingers crossed!!!

No, TV Mode is not enabled. I am using the Dark theme, but I have also tested the Windows theme and the issue remains exactly the same. I have additionally: • Reset the app completely • Uninstalled Emby Windows • Restarted Windows • Reinstalled the app from the Microsoft Store Unfortunately, the playback controls / OSD are still not visible after the clean reinstall. The issue occurs in normal desktop mode as well as in windowed, maximized and fullscreen playback.

The GT 1030 is a complete pile of e-waste, it's garbage. In Emby for Windows you can try setting Video Player to Energy Efficient and see if that helps.

Not that I'd know of. Which theme? TV Mode enabled?

Hello, I am using Emby Windows version 2.317.2.0. Video playback itself works normally, but the complete playback controls overlay / OSD is no longer visible. When I start any video and move the mouse or click inside the player, no controls appear. The play/pause button, progress bar, volume control, audio and subtitle selection, fullscreen button and all other playback controls are missing. The video continues playing normally, and player commands such as play/pause are still being processed. The issue occurs in windowed, maximized and fullscreen modes. I have already tested the following: • HDR enabled and disabled • 10-bit and 8-bit display output • NVIDIA GeForce RTX 5060 Ti • AMD Radeon integrated graphics • D3D11VA hardware decoding • Software decoding • Different MPV quality and scaling settings • Multiple video files • Windowed, maximized and fullscreen playback The behavior is always the same. The Emby client log shows that IAppRouter.showVideoOsd is called and returns successfully, but the OSD is still not visible. This makes me suspect a z-order or composition issue where the native MPV video surface is being rendered above the WebView2 playback controls. The client log also repeatedly contains the following warning when the OSD is requested: Warn WebView: error locking orientation: [object DOMException] I have attached the Emby client log and several MPV logs from tests using different graphics adapters, decoding methods and display configurations. Expected behavior: The playback controls should appear when moving the mouse, clicking inside the player, pausing playback or entering fullscreen mode. Actual behavior: The video is visible and plays normally, but the complete playback controls overlay remains hidden. The controls worked previously, but I currently cannot find any way to restore them.EmbyClient.txt Is this a known regression in Emby Windows 2.317.2.0? Is there a way to completely reset the WebView2 UI, player configuration or application data without losing the connection to the Emby server? Thank you. mpv-20260719T213156584.txt

Auf deutsch steht folgendes: "Spoiler-Informationen von ungesehenen Episoden ausblenden" "Blendet das Bild und die Übersicht für ungesehene Episoden auf den meisten Bildschirmen aus." Mich persönlich hat das "Spoiler-Information" etwas irritiert. Ein "Vorschaubilder/ Episodenbilder ausblenden" hatte ich wahrscheinlich leichter verstanden.

Horrible when you have so many tv show and movies

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?

Ja, den den Begrüßungsbanner „ Michas Film & Serien Server“ hatte ich schon vor Monaten konfigiuriert Allerdings geht es mir um diesen Button im ersten Bild oben, der erst vor kurzem zusätzlich aufgetaucht ist. Das kam erst mit einem der letzten Updates. Hier meine Einstellung dazu.

@Napsterbatersomething has changed on your end as emby has always done this.

Please add an option to hide library names on the home screen. A cleaner interface helps users quickly find tools like the age calculator without unnecessary distractions.

I did, but first i didn't cope on. now i understand cause the section tags is one of the defaults. that is briliant. thank u you have been helpful as always. i appreciate this

Hi Luke Well in Edge it plays but slow - CPU is under 100% and GPU is almost free. I had one case when video started in Brave but also slow and without HDR support (video was mostly gray). Using Emby Windows App video plays slow but on GPU (about 70% loaded).

have you tried it? The end result will be the same.

I see a minor bug. If you mark something for deletion (for example, a movie) but then change your mind, the change isn't reflected in the “Latest Movies” section on the main screen, nor on the Movies page. However, if you go into the movie itself, the change is reflected on the cover art for that specific movie. Veo un bug poco importante. Si encolas una eliminación )por ejemplo, una película), pero después la cambias, en la pantalla principal, en lo ultimo en películas no se refleja el cambio; y en la página de películas tampoco. Eso si, si entras en la película, en la carátula ya a nivel de la propia película sí se refleja el cambio.

Right, but this is not what am looking for, my ultimate goal is to share a list of several channels with all my connected clients, and the perfect way to this is playlist or collection.

Yes. This updated is now working. Great. Thank you!

It appears that version 50g fixed the issue with direct playing DD and DTS for me on both of my Shield TVs. The Android app did work for both in even when the Android TV app was broken by 48g, but I do prefer the Android TV app at this point.

I'm not sure. I guess it will require manual fixup.

Hi, how does Chrome or Edge compare?