All Activity

Hi, yes that is the goal. Thanks.

I checked the nginx side directly. The Emby vhost is a standard WebSocket reverse proxy using HTTP/1.1 with the Upgrade and Connection headers set, buffering disabled, and long read/send timeouts. There is no sub_filter, body rewriting, or other directive modifying WebSocket payloads. During the exact window where these sessions lose remote control, the nginx error log has no entries. More importantly, I pulled /Sessions live while the problem was occurring. This was one response from the same server: Emby for Android SupportsRemoteControl: false Emby for Samsung SupportsRemoteControl: false Emby for iOS SupportsRemoteControl: true Emby Web SupportsRemoteControl: true All four sessions advertise the same 39-entry SupportedCommands array. Android and Samsung are actively playing, yet the server reports them as non-controllable while iOS and Web remain controllable at the same time. That is also exactly what the Dashboard shows. Android and Samsung are actively streaming but have no pause or stop controls. The iOS session on the same server has the normal remote-control buttons. At the same time, the Emby server is logging: SessionInfosWebSocketListener failed processing WebSocket message SessionsStart System.IndexOutOfRangeException at MediaBrowser.Controller.Net.BasePeriodicWebSocketListener.Start(...) along with the corresponding FormatException in the activity log listener. The WebSocket message is reaching Emby, being identified and dispatched, and the failure is occurring inside Emby's listener code. So at this point the important distinction is not simply whether WebSockets can traverse the proxy. They clearly can. The server is making different SupportsRemoteControl decisions for different client platforms in the same /Sessions response. So I ask once again. Does 4.10.0.40 require any reverse-proxy configuration changes compared with the previous stable release? I have not found anything in the release notes or documentation saying that it does. If 4.10 changed the WebSocket, routing, header, or proxy requirements, identify what changed. The Network tab is a standard remote-access setup. Nothing there was changed with the 4.10 upgrade.

Trakt changed alot of things. Trakt Now Limits Free Users to One Connected Streaming App

Hi, please contact your server admin with this query. This Emby Community is here to discuss the software application. Emby itself does not provide any media and is not a streaming service.

To clarify, I only need to restore the programdata folder and not the system folder? My programdata folder shows an older modified date than system, so I was curious.

When I tried to look for it on a Vega OS device, it does not come up.

Please explain exactly what you are doing and what happens and also follow the instructions to send a log from the app. Thanks.

As a side note, a reverse proxy issue still would not explain why iOS, Apple TV, and the Web client continue to retain remote-control capability while Android, Samsung, and LG lose it on the same server and through the same proxy path.

The reverse proxy configuration has not changed. The same proxy, clients, user permissions, and Emby network settings work normally when the server is rolled back to the previous stable release. Updating the server back to 4.10.0.40 immediately reproduces the issue. Does 4.10.0.40 require any reverse proxy configuration changes compared with the previous stable release? I have not been able to find any documentation indicating that it does. If something changed in the WebSocket handling, upgrade requirements, routing, headers, or proxy expectations in 4.10.0.40, point me to the relevant documentation or release note. I can certainly inspect the proxy side, but that still does not explain why changing only the Emby Server version consistently enables or disables remote control. The proxy is not configured to inspect or modify WebSocket frame payloads. It is only terminating and proxying the connection. The server-side FormatException and IndexOutOfRangeException therefore still seem significant. If you believe the 404 responses are the primary issue, can you clarify what changed in 4.10.0.40 that would cause /embywebsocket to be handled differently than in the previous stable release?

Luke, I have another issue with an 1080p video on a new buyed TV, the file cannot be launched, can u diagnose the problem? regards, see attached file report. ffmpeg-transcode-24f82684-2814-48e2-9c73-7e532d048f38_1.txt

Navigate to Manage Emby Server -> User Sessions

But do you really want that overlay (or any overlay) on the backdrop? I don't think so because it is going to be there wherever the backdrop is shown.

Installed. But how can I See the Data you posted?

Hi dear, My account especially arabic movies are not updated thanks

server-A_native_2026-09-14.log server-B_concurrent-notification-timeout.log server-B_native_2026-09-13.log server-C_docker_2026-09-14.log SYMPTOMS_AND_DIAGNOSIS_EN.txt

My mega thanks for implementing this. I use both Emby and MA and this provider for MA is fantastic. Emby is MUCH better at handling music files with less than perfect metadata and also pulling in additional metadata from external sources and also artwork. MA is crap for that and too coupled to MusicBrainz, which used to be the source of truth but is no longer that in this world of digital reissues and stuff (Discogs is much better, and supported by Emby). So again: THANK YOU for providing this Emby/MA integration

Any news on this? I will second MrPancake's motion that having a way to persist diagnostic options would be nice. I too need the "Disable Hardware Subtitle Overlay" setting disabled for my system to perform for HD and 4K playback with PGSUB subtitles. I understand that the feature might not be completely stable at the moment (I haven't encountered any issues though). And so understand the reluctance to add options to persist these options easily, so that someone might do so accidentally. But if we could get an option to set the options in an ini-file or similar, so that a determined admin could do so, that would be much appreciated.

I have a Latte Panda Delta 864 with Intel N5105 running Debian 13 with the latest Emby container under Docker. Transcoding enabled and compose updated with GIDLIST, but transcoding kept failing with: [h264_qsv] Selected ratecontrol mode is unsupported This fixed it for me: Update repo sources to include non-free Install intel-media-va-driver-non-free (and vainfo) Add 'options i915 force_probe=1 enable_guc=2' in /etc/modprobe.d/i915.conf

two different drives,

They must be taking longer to test your years models. Sometimes I don't think they even test 2018 models anymore and just let it fly through.

Hello guys, i have the same issue with playback on Google Nest Mini (2. Gen). The problem description is the same as Robin5446's. So far I tested without success: - Android Device with and without Emby App as Control Point - iPhone Device with Emby App as Control Point - Windows Device with Emby in different Browsers as Control Point - Different Google Nest Mini Speakers, also tried FW reset - Building New Emby Server from Scratch with complete reconfiguration The problem occurred a few months ago. Didn't have the time to look deeper into it. Seems like the Nest Mini can't connect to emby server anymore. I have the following configuration: - Emby as docker container with latest official image 4.10.0.40 (did not work in 4.9X before either) - The container is attached to an ngnix reverse proxy for remote access and to the local LAN via docker macvlan driver and working properly, all devices can reach the embyserver - https is enforced and handled by the reverse proxy and certificate is from letsencrypt. External Emby Port ist 443. - All devices (server, control points and receivers) are on the same local subnet --> Everything is working fine (local and remote access) except chromecast. The Configuration has worked fine for years so my guess is a change in the Google Nest Mini or maybe a problem with the HTML5 Receiver App for Emby? Could you please also check this? At the same time, I will get another Google Cast device to test. Anyway, Is there a way to anonymize the Emby log? I used the switch in the dashboard but still a lot of clear plain unchanged private info. Is it working? Thank you!

Nice to hear.

Still not available here and my tv is newer than FrostBytes...

It was working, since upgrading to the 4.10 version. Then I spotted an compatibility update to the DLNA plugin 1.5.7.0 So I played a few seconds of a few tracks to make sure they counted as played. Then I restarted the server to apply the DLNA plugin upgrade and it hasn't updated the playcount of any tracks played via the dlna server since, although I can see them being played in the dashboard. You can see tracks being played that were upfated in "before upgrade.txt" at about 06.12 this morning. Any tracks in "after upgrade.txt" from about 11.02 are not being counted as played. If it makes a difference I am playing to a Wiim device using their dlna browser/player before upgrade.txt after upgrade.txt

OK, looking good!