4.10.0.40 Regression - Android and Samsung sessions no longer remotely controllable

[Cr8iveLosr 102]

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 102]

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