mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
[Issue]: Remote Control / Display Mirror not working #6049
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @aaruni96 on GitHub (Jun 23, 2024).
Please describe your bug
Ever since the update to 10.9 (currently 10.9.6) the remote control feature no longer works. Feels like its a repeat of #496 all over again. It used to work in 10.8.
My use case is, I like to play media on jellyfin-media-player on desktop, and control it via my mobile phone from the couch / bed.
Here's how the UI looks like on the mobile, while something is playing on the desktop. The pause/play button works, as does the volume slider and the mute button. Seek functionality does not work.
Reproduction Steps
Jellyfin Version
10.9.0
if other:
No response
Environment
Jellyfin logs
Found this to be quite interesting: 192.168.0.103 is my mobile phone from which I try to remote control
FFmpeg logs
No response
Please attach any browser or client logs here
No response
Please attach any screenshots here
Code of Conduct
@jellyfin-bot commented on GitHub (Jun 23, 2024):
Hi, it seems like your issue report has the following item(s) that need to be addressed:
This is an automated message, currently under testing. Please file an issue here if you encounter any problems.
@jellyfin-bot commented on GitHub (Oct 22, 2024):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@aaruni96 commented on GitHub (Oct 22, 2024):
This is still a problem for me
@XqeH57r commented on GitHub (Nov 9, 2024):
I am having the same issue, with same error message. Work around is making the user an admin. Not a great solution but it worked for me for now.
@not-root commented on GitHub (Dec 22, 2024):
Still present in 10.10.3. Observed with all combinations of:
Notably, only the controlling device needs to be signed into an admin account. The device being controlled can be signed into any other account.
@gnattu commented on GitHub (Dec 22, 2024):
“Allow this user to control other devices” is a separate permission that can be granted to a user in its user setting page, does that option work? The last time I checked a user with that permission can control other devices.
@aaruni96 commented on GitHub (Dec 22, 2024):
I do not find this option. I only find two options in the remote control section, see screenshot. The option "allow remote control of other users" seems dangerous
@Xameon42 commented on GitHub (Dec 23, 2024):
I guess that the problem is in the following commit, specifically in line 73 in Jellyfin.Api/WebSocketListeners/SessionInfoWebSocketListener.cs
It would also fit in terms of time, as the commit has been present since v10.9.0.
For testing I removed the if statement and was able to successfully control the session again, without an admin account.
Also seeking seems working again.
Unfortunately I'm not familiar enough with the codebase to have a good solution to customize the check so that users can only control their own session and only admins can control all sessions.
@jellyfin-bot commented on GitHub (Apr 22, 2025):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@aaruni96 commented on GitHub (Apr 28, 2025):
This issue still affects me :(
@felix920506 commented on GitHub (Apr 28, 2025):
@aaruni96 the setting is that "Allow remote control of other users", see if turning on that works
@aaruni96 commented on GitHub (Apr 28, 2025):
On 10.10.6, this still doesn't work. I will need some time to run updates and try on 10.10.7, but the changelog doesn't mention it.
@felix920506 commented on GitHub (Apr 28, 2025):
Have you tried not going through your Nginx reverse proxy and directly connecting to Jellyfin?
@aaruni96 commented on GitHub (Jun 10, 2025):
Does not work even if I connect directly to jellyfin by bypassing nxinx
@Xameon42 commented on GitHub (Jun 10, 2025):
Maybe same issue than #13709 ?
@aaruni96 commented on GitHub (Jun 10, 2025):
Looks like the same symptoms, yes
@KGT1 commented on GitHub (Sep 29, 2025):
Please test again on latest rc.
should be fixed by #13767
@aaruni96 commented on GitHub (Oct 20, 2025):
I can't easily test on release candidates, so I haven't tried. But the new release just hit, and on version 10.11.0, this problem still persists for me.
Edit: The problem seems to have slightly improved, but not quite fixed. I can now see some metadata on the mobile app, and controls are slightly better, but it doesn't "live update", i.e., when the playback has moved to 05:05, the mobile app still shows it "stuck" on 01:35.
I can provide more details later.
Edit edit
smal update:
The mobile screen seems to update every time admin refreshes the dashboard screen.
@KGT1 commented on GitHub (Oct 22, 2025):
Sorry but that seems like a new bug and not what you reported in this issue at all. please open a new bug with steps to reproduce. also make sure its a server issue and not an android issue.
@aaruni96 commented on GitHub (Oct 22, 2025):
While I am starting to suspect this is an android client issue, how would I make sure ?
@KGT1 commented on GitHub (Oct 23, 2025):
generally you could try it out with different clients. its always a little hard to figure out in the jellyfin ecosystem, but if you give exact steps to reproduce, best with fresh and up to date instances of the server and clients, it would be way easier to figure out.
@aaruni96 commented on GitHub (Nov 26, 2025):
I didn't change anything (or at least I think I didn't change anything), but after a few restarts of both the server and the clients for other unrelated reasons, it appears to work now.