4.10.0.40 Regression - Android and Samsung sessions no longer remotely controllable

[Cr8iveLosr 103]

After updating my server from the previous stable release to 4.10.0.40, remote control of Android and Samsung sessions is now broken.

To be clear, nothing in my setup changed other than the Emby Server version.

Same server.
Same network configuration.
Same reverse proxy.
Same clients.
Same users.
Same administrator account.
Same firewall and port forwarding.

The regression appeared immediately after updating the server to 4.10.0.40.

Remote users can still connect, authenticate, browse the library, and start playback normally. This is not a remote connection or login issue.

The problem is that once these clients connect, Emby now treats them as not remotely controllable.

I checked the live /Sessions data directly and found:

• Emby for Android: SupportsRemoteControl: false
• Emby for Samsung: SupportsRemoteControl: false
• Emby Web: SupportsRemoteControl: true
• Emby for iOS: SupportsRemoteControl: true
• Emby for Apple TV: SupportsRemoteControl: true

This also matches what is shown in the Emby Dashboard. Android and Samsung sessions no longer expose the normal administrator playback controls. Pause, stop, seek, and the other remote playback controls are unavailable.

This is especially significant on my server because most of my users are using Android-based devices, so this regression effectively removes administrator remote control from the majority of active sessions.

I also checked:

GET /Sessions?ControllableByUserId=<adminUserId>

The Android sessions are completely absent from the controllable session list.

At the same time, the affected Android sessions still advertise a populated SupportedCommands array and valid PlayableMediaTypes. The sessions are active, playback information is present, and the server is receiving their playback state, but SupportsRemoteControl is still being set to false.

There is another change in 4.10 worth noting. SupportsMediaControl is no longer present in the /Sessions response at all. The field is not set to false. It is simply absent.

According to Emby's API documentation, SupportsMediaControl is the client capability that indicates whether the client accepts remote control commands. SupportedCommands is a separate capability list.

Reverting confirms the regression

I also reverted the server back to the previous stable release without changing anything else in the environment.

The remote controls immediately came back.

Android clients were once again shown as controllable in the Emby Dashboard and could receive remote playback commands.

They remain controllable for roughly 60 seconds before the separate, longstanding WebSocket timeout problem occurs.

That older WebSocket issue has existed for years and is already documented elsewhere. So I wont reinvent that wheel here.

The important distinction is:

Previous stable: Android sessions are remotely controllable when they connect. Remote control later disappears because of the longstanding WebSocket timeout.

4.10.0.40: Android and Samsung sessions are classified as non-controllable from the beginning. The Dashboard does not provide the controls at all.

So while the existing WebSocket issue already made remote control unreliable, something changed in 4.10.0.40 that has made the situation considerably worse.

This is reproducible simply by changing the Emby Server version. No other configuration changes are required.

[Luke 43099]

Hi, I just did a quick test and I was able to remote control Emby for Android.

Did you check the remote control permissions for the user?

[Cr8iveLosr 103]

Yes, the permissions have been checked. Nothing in the user permissions, server configuration, reverse proxy, clients, or network configuration changed between the previous stable release and 4.10.0.40.

That is also why I specifically tested this by reverting the server version.

On the previous stable release, the same Android users and same devices immediately show as remotely controllable in the Dashboard and /Sessions reports them accordingly. After upgrading the same server back to 4.10.0.40, those same Android sessions report:

SupportsRemoteControl: false

and they disappear from:

GET /Sessions?ControllableByUserId=<adminUserId>

The Dashboard reflects the same state by removing the playback controls.

No permissions are being changed between these tests. Only the Emby Server version is changing.

Also, was your quick Android test performed with a remote Android client connecting through a reverse proxy, or was the Android device on the local network?

The issue I am reporting is specifically with remote users. They can connect, authenticate, browse, and play normally, but 4.10.0.40 immediately classifies the Android session as non-controllable.

Web, iOS, and Apple TV sessions on the same server still report SupportsRemoteControl: true, so this is not a general administrator permission issue either

[JMSolo 1]

Just chiming in to confirm I am seeing the exact same thing, so this is not a one-off. The only thing that changed on my end was updating to 4.10.0.40. I did not touch a single permission, I did not change any settings, and nothing in my environment changed. It just broke after the update.

@Luke respectfully, this is not a user permission issue, and it is pretty easy to rule that out. On the same server, with the same users and the exact same permissions, my iOS and Apple TV clients are perfectly controllable. I literally sat down and streamed a show from my iPhone, the playback controls were right there, they worked, and messages went through fine. Meanwhile the Android and Samsung sessions from those same users show no controls at all, and messages never reach them. A per-user permission cannot explain a break that only follows the client platform. Same user, iOS works, Android does not. That alone tells you it is server side.

And to be clear, this is not some third party tool or API script doing something weird on my end. I see it right inside Emby's own dashboard. Every Android and Samsung stream in there only shows the Message option, no play, no pause, no stop, and even that message does not actually get delivered to the user.

I also want to back up what @cr8iveLosr said about this being a remote thing. To be upfront, this is just me and my immediate family using this server. It is a normal family setup. We simply connect in from outside the house, over the internet, to a self hosted server sitting behind an nginx reverse proxy on its own subdomain over HTTPS. This is all remote, not LAN. That distinction seems to matter a lot here, and it makes me think your quick test that worked on Android may have been done locally. If you hit it the way my family actually does, remotely through a reverse proxy and subdomain, I think you will see exactly what we are seeing.

@cr8iveLosr already laid out the API evidence and it lines up exactly with what I am seeing. SupportsRemoteControl comes back false for Android and Samsung and true for iOS, Apple TV, and Web, all in the same /Sessions response with one admin key. The SupportsMediaControl field is completely gone from the payload now, and it was there before 4.10. Those broken sessions also do not show up at all under /Sessions?ControllableByUserId. Your own capabilities docs say controllability is declared through ClientCapabilities.SupportsMediaControl, and these clients are still sending a full SupportedCommands list, so the server has simply stopped treating them as controllable.

You mentioned you did a quick test and Android worked for you, so this is probably build or app version specific. Can you tell us the exact server build and the exact Android app version you tested against, and whether you tested a remote session through a reverse proxy or just on your LAN? Because rolling back to the previous stable brings control right back, which points pretty clearly at something that changed in 4.10 itself.

[yocker 1921]

Works fine for me.



As Luke said, sure you have enabled the option in the user settings?

[JMSolo 1]

Interesting, @yocker. On my end this really is not a permissions thing, because nothing changed except updating the server to the latest Emby stable. And like I said above, I rolled back to the previous stable and remote control came right back with no other changes. That is about as clean a before and after as it gets.

I would ask you the same thing I would ask about any test here, because the details really do matter. Is your setup a local install on the same network, or are your clients connecting in remotely through a reverse proxy and subdomain? On my side iOS and Apple TV are golden, the controls work and messages go through, while Android and Samsung are the ones that lost control. So if you are testing on the LAN, or you are not on an Android or Samsung client, that would explain why you are not seeing it.

To add to this which setting are you referring to specifically? I have toggled every user setting on and it makes no difference. I also tested this with a full admin account, my own, and the issue is exactly the same there. An admin account already has every permission there is, so if remote control fails even for the admin, that rules permissions out entirely. And if you are saying the admin is somehow lacking a permission to remote control, then that is a separate bug on its own.

That is really why I keep coming back to the setup. Same server, same account, same permissions: iOS and Apple TV work, Android and Samsung do not. There is no per user permission that disables remote control for only Android and Samsung while leaving iOS working for that same user. That points at the client platform and the 4.10 server, not a toggle.

Not trying to be difficult, just trying to pin down the exact conditions so we are actually comparing the same thing.

Edited 1 hour ago by JMSolo

[Cr8iveLosr 103]

14 minutes ago, yocker said:

Works fine for me.

As Luke said, sure you have enabled the option in the user settings?

Thanks for chiming in. This question was already answered, not once, but twice.

[Luke 43099]

59 minutes ago, Cr8iveLosr said:

Yes, the permissions have been checked. Nothing in the user permissions, server configuration, reverse proxy, clients, or network configuration changed between the previous stable release and 4.10.0.40.

That is also why I specifically tested this by reverting the server version.

On the previous stable release, the same Android users and same devices immediately show as remotely controllable in the Dashboard and /Sessions reports them accordingly. After upgrading the same server back to 4.10.0.40, those same Android sessions report:

SupportsRemoteControl: false

and they disappear from:

GET /Sessions?ControllableByUserId=<adminUserId>

The Dashboard reflects the same state by removing the playback controls.

No permissions are being changed between these tests. Only the Emby Server version is changing.

Also, was your quick Android test performed with a remote Android client connecting through a reverse proxy, or was the Android device on the local network?

The issue I am reporting is specifically with remote users. They can connect, authenticate, browse, and play normally, but 4.10.0.40 immediately classifies the Android session as non-controllable.

Web, iOS, and Apple TV sessions on the same server still report SupportsRemoteControl: true, so this is not a general administrator permission issue either

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[yocker 1921]

46 minutes ago, JMSolo said:

Interesting, @yocker. On my end this really is not a permissions thing, because nothing changed except updating the server to the latest Emby stable. And like I said above, I rolled back to the previous stable and remote control came right back with no other changes. That is about as clean a before and after as it gets.

I would ask you the same thing I would ask about any test here, because the details really do matter. Is your setup a local install on the same network, or are your clients connecting in remotely through a reverse proxy and subdomain? On my side iOS and Apple TV are golden, the controls work and messages go through, while Android and Samsung are the ones that lost control. So if you are testing on the LAN, or you are not on an Android or Samsung client, that would explain why you are not seeing it.

To add to this which setting are you referring to specifically? I have toggled every user setting on and it makes no difference. I also tested this with a full admin account, my own, and the issue is exactly the same there. An admin account already has every permission there is, so if remote control fails even for the admin, that rules permissions out entirely. And if you are saying the admin is somehow lacking a permission to remote control, then that is a separate bug on its own.

That is really why I keep coming back to the setup. Same server, same account, same permissions: iOS and Apple TV work, Android and Samsung do not. There is no per user permission that disables remote control for only Android and Samsung while leaving iOS working for that same user. That points at the client platform and the 4.10 server, not a toggle.

Not trying to be difficult, just trying to pin down the exact conditions so we are actually comparing the same thing.

Works both on local, through VPN and through just normal remote and with promote proxy. Works with my users as well.



For the admin account that you want to be able to control others.

 

Edited 1 hour ago by yocker

[JMSolo 1]

@yocker, "Allow remote control of shared devices" is not what governs this. That policy lets an account send content to shared devices, the DLNA-style ones with nobody signed in. The sessions in question are not shared devices, they are normal user sessions with a user signed in and actively streaming (Emby for Android on the TV boxes, and a Samsung TV). So that toggle does not even apply to them, and either way it is a permission on the controlling account, not something that decides whether a given client platform can be controlled.

Here is the proof it is not that setting. The exact same admin account (and other users) keep full remote control on iOS and Apple TV with no problem. That same account logs in on a Samsung TV, which had working controls before this update, and there are none. Same account, controls work on one platform and vanish on another. A user or account permission cannot do that, because it would kill control everywhere, not only on Samsung and Android.

To remove all doubt, I turned that setting on for my own admin account and I had it streaming a show, and there were still zero controls for it in the Emby dashboard. So the toggle is not the fix.

I have already rolled back to the previous stable, since I rely on these controls to manage my kids' streams. Hopefully the logs cr8iveLosr is supplying help Luke narrow this down.

Edited 49 minutes ago by JMSolo

[Cr8iveLosr 103]

1 hour ago, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

embyserver-redacted-2026-09-15.txt

See attached. It took a while to tail the relevant logs because "Anonymize log contents" does not do a very good job, so I had to manually scrub quite a bit of information from the log. However, here is what I found.

The capture was taken while the issue was actively occurring, with remote Android clients streaming normally but showing no remote-control options in the Dashboard.

The server explicitly identifies the affected Android playback as remote:

IsPlayback: true, isInLocalNetwork: False

Playback itself continues normally. The Android clients continue reporting playback progress and receiving successful responses from the server.

What stands out is that, during the same window, the server repeatedly logs:

SessionInfosWebSocketListener failed processing WebSocket message SessionsStart

with:

System.IndexOutOfRangeException

inside:

MediaBrowser.Controller.Net.BasePeriodicWebSocketListener.Start

There are six occurrences of this during the short capture.

At the same times, the server also repeatedly logs:

ActivityLogWebSocketListener failed processing WebSocket message ActivityLogEntryStart

with a System.FormatException, again inside BasePeriodicWebSocketListener.Start.

There are also six occurrences of that error.

I also found three 404 responses to:

GET /embywebsocket?api_key=...&deviceId=...

while the affected Android sessions are active and continuing to report playback normally.

I am not claiming that any one of those entries, by itself, proves the root cause. What I am pointing out is that there are repeated server-side WebSocket processing failures occurring at the same time the remote-control problem is present.

One other limitation of this log is that Info-level logging does not show the request body for /Sessions/Capabilities/Full, so it does not expose the actual SupportsMediaControl value being declared by the client. The only capability registration that happened during this particular capture window was Apple TV, which completed successfully with a 204. The Android sessions were already active when I started the capture, so I am not interpreting the absence of an Android capability registration in this window as proof that Android never registered one.

The important part remains that this is reproducible by changing only the Emby Server version. On 4.10.0.40 these remote Android sessions are immediately treated as non-controllable. Reverting to the previous stable restores the Dashboard controls for the same clients, users, permissions, reverse proxy, and network configuration, until the longstanding WebSocket timeout occurs.

[Cr8iveLosr 103]

Adding to the above, I also tested Samsung and LG TVs using the latest app versions available from their respective app stores.

Both show the same behavior. As soon as the second user starts playback, there are no remote-control buttons available in the Emby Dashboard for those sessions.

That makes this broader than an Android app-version issue. I am seeing the same loss of remote control across Android, Samsung, and LG clients on 4.10, while iOS, Apple TV, and Web remain controllable.