All Activity

Here is the thread you will want to follow: https://emby.media/community/topic/139523-embyforkodi-next-gen-12xx-support/ Load the Kodi Companion plugin from the Emby plugin library on your server Download the 4 plugins of quickmic's from the first post in the link above Install the Service plugin first in Kodi, then load the other 3 plugins in Kodi If you have any question about the plugin post in the thread above and I'm sure someone will respond

Thanks @FrostByteit's definitely 'baby steps' for me as I hadn't really dug into all this before and your advice was amazing. I dont mind forking out money for a good device but I had a nagging feeling I had all the ingredients I needed to get the most. I must admit it wasnt very easy to get all the drivers and settings sorted on the Windows NUC but once I did I'm guessing it's a one-time thing (versus a Shield plug-and-play I'm assuming). I dont watch streaming platforms I have all my media local on my NUC. So one last request please - can you point me to the Kodi/quickmic's plugin info and where to source that so I can give that a try as a client?

Also, if your NUC and the Emby client can pass HDR10+ (since you have a Samsung TV and no DV) then that's another plus for the NUC. The Shield does NOT pass HDR10+ as of yet.

If you got Atmos and HDR to trigger and are happy that is good. I believe running the Emby client on the NUC was one thing I did mention in that journal of long-winded information I gave you. I just didn't have any experience with the Windows client and MPV, etc. to say how well it worked. Though I would imagine it's probably better than using your Xbox as a client. Yes, I've used quickmic's plugin and find it to be very good. Basically, it sync's Emby's db with Kodi's and brings some capabilities along with it that Kodi doesn't provide. If you like to play with skins and want more leeway in tweaking your client, the way you want it to look then the plugin may be for you.

@Neminemit was considerably longer than that as you probably missed, I have a NUC11TNHi3 running as an EMBY server directly into my HW-Q990c sound bar. I spent just on 3 hours yesterday on the NUC side alone updating drivers and configuring to hear what I was missing out of the Samsung Tizen App. I was asking these questions given the higher experience from the community to help me - which you didn't appear to offer anything of use (noted). I'm glad to say @FrostBytethat your advice and help was beneficial as I managed to get the NUC to output TrueHD to the Soundbar through the Emby theatre App running on the same NUC. My config was NUC>HW-Q990C>Samsung The Frame LS03B [eARC] My original question was "DO I need a nVidia Shield Pro to get the best out of my sound bar hardware" given I listed all my kit upfront. ChatGPT replied "NO your NUC is actually more powerful than a Shield" and you have it already negating the need to spend more on the config Interestingly ChatGPT also recommended I run Kodi on the NUC with EMBY integration (same NUC running Emby Server) as a recommended experience which I found a little odd but I'm going to give it a go. I'd be keen on @FrostByteor @Lukecomments on that. On another massive "plus" side, by running Emby Theater on the NUC PC that runs the EMBY Server, I'm gaining many versions newer than my old way of running the Tiezen Emy App which is still stuck on 2.2.8 due to the long waits caused by Samsung. So all in all it feels like I have all the hardware I need to get the most out of my Soundbar, I just didn't realize all the issues/transcoding etc that was blocking me by running the Tiezen App on my LS03B The Frame TV

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.