mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Remote Control only visible and working for Admin Users #6300
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 @ghost on GitHub (Sep 25, 2024).
This issue respects the following points:
Description of the bug
If I select a device for remote control with a usere without admin rights the control bar at the bottom is missing and the remote control layer is not working.
With an admin user everything is working fine. This happens in web version and the MacOS App.
Reproduction steps
What is the current bug behavior?
remote control is not working for non admin users
What is the expected correct behavior?
remote control should work for non admin users the same for admin users
Jellyfin Server version
Older*
Specify commit id
No response
Specify unstable release number
No response
Specify version number
10.9.10
Specify the build version
10.9.10
Environment
Jellyfin logs
FFmpeg logs
No response
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
No response
@felix920506 commented on GitHub (Sep 25, 2024):
What type of device are you trying to control? Is it DLNA?
@ghost commented on GitHub (Sep 25, 2024):
It doesn't matter which device. The behavior is the same with every device (Smart TV, Web Browser, App).
It works as soon as I check "Allow this user to manage the server" for a user.
@gnattu commented on GitHub (Sep 25, 2024):
Did you enable any of these?
@ghost commented on GitHub (Sep 26, 2024):
Both are enabled.
@josephfh commented on GitHub (Oct 2, 2024):
Experiencing the same with a fresh install on linux. Version 10.9.11
@zsamiatt commented on GitHub (Oct 29, 2024):
I updated jellfyn docker to 10.10.0. The send to function working with admin right in this version. No error in log. No settings.
@ghost commented on GitHub (Oct 29, 2024):
Congratulations, now the "cast to device" function isn't even working any more without admin rights. Clicking the Button shows up an endless spinner. Tested it with the lates Mac client and the web version.

I recommend everyone not to update to version 10.10.0.
@nielsvanvelzen commented on GitHub (Oct 29, 2024):
No need for salty comments, you won't achieve anything with that. I've tested it just now and everything is working fine for me. Without more information about your setup we won't be able to help.
@ghost commented on GitHub (Oct 29, 2024):
LOL, without more information about your setup you can claim everything.
Setup:
Before version 10.10.0 I can take control over an other device by clicking "cast to device" but the control bar at the bottom wan't be displayed with the given settings.
After upgrading to 10.10.0 a click on "cast to device" is only working if "Allow this user to manage the server" (in my opinion this is equal to an admin) is ticked. If not, there will be an endless spinner displayed with all clients. So the update fixed the missing control bar by showing an endless spinner ... congratulations again ... bug fixed by creating another one.
A few versions ago everything worked without the need to give users the right to manage the server. Now not even the "cast to device" function is working without these right.
So asking for the setup is a bullshit argument because with the admin checkbox ticked everything is working like expected. So this is not an issue of the setup. It's an implementation issue.
If it is wanted from you to not allow casting to devices for non admin users then disable the button or just don't show it. This would be a much better UX then the current behavior.
So I guess its time to switch to a more professional media server with more professionals...
This error is desplayed in the log:
@snaakey commented on GitHub (Oct 29, 2024):
Having the same issue. When clicking on the cast icon the request to
https://example.com/Sessions?ControllableByUserId=<id>returns a 500 with the same trace as above. I'm also running Jellyfin 10.10.0 and it also only happens with non admin accounts.@ghost commented on GitHub (Oct 29, 2024):
Are you kidding marking a hint that the "so called fix" doesn't work as "off-topic".
So, I move to Emby now. This is very unprofessional here.
@spacemanspiff2007 commented on GitHub (Oct 30, 2024):
I'm having the same issue
@ghost commented on GitHub (Oct 30, 2024):
My suggestion is to switch to Emby ... the devs here doesn't care about the bugs.
@ghost commented on GitHub (Oct 30, 2024):
LOL - nielsvanvelzen fixed a bug that he do not have on his system. And he is censoring comments. Best dev of the world.
@cvium commented on GitHub (Oct 30, 2024):
No one is censoring your comments. I marked it as abuse because it is.
Remember the human. Consider this your last warning.
@ghost commented on GitHub (Oct 30, 2024):
LOL ... last warning ... funny. Fix your bugs instead of threatening people reporting these bugs. So typical ...
@joshuaboniface commented on GitHub (Oct 30, 2024):
@moonshRiner1337 Congratulations, you are banned from contributing to Jellyfin. You were warned to treat people with respect and you continue to abuse our team. You can take your "business" somewhere else.
This problem seems to still exist, so this issue can remain open.
@felix920506 commented on GitHub (Oct 31, 2024):
closing as fixed by #12915
@spacemanspiff2007 commented on GitHub (Oct 31, 2024):
Thank you for the fix. Is there any change it will make it into an official hot fix in the next couple of days?
@crobibero commented on GitHub (Oct 31, 2024):
There is no ETA for the next release of Jellyfin (10.10.1)