Feature request: Shared casting mechanism #1221

Closed
opened 2026-02-06 20:39:24 +03:00 by OVERLORD · 8 comments
Owner

Originally created by @iwalton3 on GitHub (Jan 19, 2020).

I maintain the client Jellyfin MPV Shim. I would like to be able to add multi-user support so that a shared HTPC could be used by multiple users as a cast target without having to log off one user and have the other log in.

I've explored two ways to do this, and there are issues with both of them.

Option 1: Add multiple users to a session. (Test branch here.)
Benefits:

  • This allows the client to be controlled by multiple different users.
  • Multiple users do not have to log into the client to allow them to cast.

Problem:

  • The Jellyfin server updates the media playback state for each user who is in the session, regardless of if they are the controlling user or now. There currently is no parameter in the API I'm aware of that limits the playstate updates to the controlling user.
  • Additionally, although you can add and remove additional users from the session, you cannot remove the user who logged in to the player from the session, even if the controlling user is a different user. (This means the authorized user is always going to get the playstate updates.)
  • Even if a parameter is added, having to add many users to a session is a lot of overhead and increases client load times if you want to allow many users access to the client.

Option 2: Add multiple users to a single client by opening multiple sessions. (Technically allowed by current implementation, but does not work due to client id issue.)
Benefits:

  • This allows the client to be controlled by multiple different users.

Problem:

  • The Jellyfin server does not allow a single client to have multiple active logins, so multiple client ids would have to be assigned to a single client. This is not ideal, and may lead to other problems.
  • An authorization and active websocket connection would be needed for each user who wants to use the client.
  • Multiple users would have to log into a single client, which is bad for usability.

I think that the best way to accomplish this is probably not one of the methods I attempted above, but instead some way to obtain a generic session. This generic session would have no rights until a user casts to it, at that point the session takes on the characteristics of the controlling user until they stop casting.

It is also worth noting that the setting to allow a user to control another user's clients is not a solution to this issue, because the playstate updates still end up going to the original user who signed into the client, and not the user controlling the client. (It also isn't ideal to give that permission to users just to let them cast to an HTPC.)

This was discussed here: https://matrix.to/#/!xGCydtJPWedDaDHfzm:matrix.org/$1579108032233429GGfZz:matrix.org?via=matrix.org&via=bonifacelabs.ca&via=plsno.com

Originally created by @iwalton3 on GitHub (Jan 19, 2020). I maintain the client [Jellyfin MPV Shim](https://github.com/iwalton3/jellyfin-mpv-shim). I would like to be able to add multi-user support so that a shared HTPC could be used by multiple users as a cast target without having to log off one user and have the other log in. I've explored two ways to do this, and there are issues with both of them. **Option 1: Add multiple users to a session.** (Test branch [here](https://github.com/iwalton3/jellyfin-mpv-shim/compare/multi-user).) **Benefits:** - This allows the client to be controlled by multiple different users. - Multiple users do not have to log into the client to allow them to cast. **Problem:** - The Jellyfin server updates the media playback state for each user who is in the session, regardless of if they are the controlling user or now. There currently is no parameter in the API I'm aware of that limits the playstate updates to the controlling user. - Additionally, although you can add and remove additional users from the session, you cannot remove the user who logged in to the player from the session, even if the controlling user is a different user. (This means the authorized user is always going to get the playstate updates.) - Even if a parameter is added, having to add many users to a session is a lot of overhead and increases client load times if you want to allow many users access to the client. **Option 2: Add multiple users to a single client by opening multiple sessions.** (Technically allowed by current implementation, but does not work due to client id issue.) **Benefits:** - This allows the client to be controlled by multiple different users. **Problem:** - The Jellyfin server does not allow a single client to have multiple active logins, so multiple client ids would have to be assigned to a single client. This is not ideal, and may lead to other problems. - An authorization and active websocket connection would be needed for each user who wants to use the client. - Multiple users would have to log into a single client, which is bad for usability. I think that the best way to accomplish this is probably not one of the methods I attempted above, but instead some way to obtain a generic session. This generic session would have no rights until a user casts to it, at that point the session takes on the characteristics of the controlling user until they stop casting. It is also worth noting that the setting to allow a user to control another user's clients is not a solution to this issue, because the playstate updates still end up going to the original user who signed into the client, and not the user controlling the client. (It also isn't ideal to give that permission to users just to let them cast to an HTPC.) This was discussed here: https://matrix.to/#/!xGCydtJPWedDaDHfzm:matrix.org/$1579108032233429GGfZz:matrix.org?via=matrix.org&via=bonifacelabs.ca&via=plsno.com
OVERLORD added the feature label 2026-02-06 20:39:24 +03:00
Author
Owner

@JustAMan commented on GitHub (Jan 20, 2020):

Note: we track feature requests here - https://features.jellyfin.org/

@JustAMan commented on GitHub (Jan 20, 2020): Note: we track feature requests here - https://features.jellyfin.org/
Author
Owner

@iwalton3 commented on GitHub (Jan 20, 2020):

It looks like this is a duplicate of https://features.jellyfin.org/posts/319/mark-device-as-shared.

@iwalton3 commented on GitHub (Jan 20, 2020): It looks like this is a duplicate of https://features.jellyfin.org/posts/319/mark-device-as-shared.
Author
Owner

@dkanada commented on GitHub (Jan 20, 2020):

@iwalton3 thanks for linking this issue, it was an excellent breakdown of the possible solutions that exist at the moment.

@dkanada commented on GitHub (Jan 20, 2020): @iwalton3 thanks for linking this issue, it was an excellent breakdown of the possible solutions that exist at the moment.
Author
Owner

@dkanada commented on GitHub (Jan 20, 2020):

Also, if you're willing to look through the server and implement the functionality it would defininitely be an acceptable feature to include.

@dkanada commented on GitHub (Jan 20, 2020): Also, if you're willing to look through the server and implement the functionality it would defininitely be an acceptable feature to include.
Author
Owner

@SteveDinn commented on GitHub (Sep 12, 2020):

I wonder if it would be simpler or easier to think about this as a user who lets all other users control their sessions. It doesn' have to be a shared device, but just a permissive user.

@SteveDinn commented on GitHub (Sep 12, 2020): I wonder if it would be simpler or easier to think about this as a user who lets all other users control their sessions. It doesn' have to be a shared device, but just a permissive user.
Author
Owner

@iwalton3 commented on GitHub (Sep 12, 2020):

The problem is play tracking. The playback activity needs to go back to the person playing the media somehow.

@iwalton3 commented on GitHub (Sep 12, 2020): The problem is play tracking. The playback activity needs to go back to the person playing the media somehow.
Author
Owner

@bedrin commented on GitHub (Sep 7, 2021):

@iwalton3 I'm trying to come up with a workaround for it. For two users for a start. Do you think having two instances of jellyfin-mpv-shim connected to single mpv via AF_SOCKET would work? Or do I need to code a small multiplexer to rule them?

UPD: I've finished my experiment:

  1. started playing video A using first instance of jellyfin-mpv-shim (under account foo)
  2. started playing video B using second instance of jellyfin-mpv-shim (under account bar)
  3. I got movie B on TV screen. However jellyfin for user foo was still showing that movie A is playing, moreover time was synchronised with user bar watching movie B

I guess it makes sense and it is expected. So it is a viable workaround but a bit suboptimal)

@bedrin commented on GitHub (Sep 7, 2021): @iwalton3 I'm trying to come up with a workaround for it. For two users for a start. Do you think having two instances of `jellyfin-mpv-shim` connected to single `mpv` via AF_SOCKET would work? Or do I need to code a small multiplexer to rule them? **UPD**: I've finished my experiment: 1. started playing video `A` using first instance of `jellyfin-mpv-shim` (under account `foo`) 2. started playing video `B` using second instance of `jellyfin-mpv-shim` (under account `bar`) 3. I got movie `B` on TV screen. However jellyfin for user `foo` was still showing that movie `A` is playing, moreover time was synchronised with user `bar` watching movie `B` I guess it makes sense and it is expected. So it is a viable workaround but a bit suboptimal)
Author
Owner

@wmtang2 commented on GitHub (Apr 3, 2024):

mpvshim-mu
I've taken another approach to make it easier to switch users in the GUI. Server address, username and passwords are stored and retrieved to logon as selected by user. Password storage done by keyring. An additional users.json created to store username and server.
gui_mgr.zip

@wmtang2 commented on GitHub (Apr 3, 2024): ![mpvshim-mu](https://github.com/jellyfin/jellyfin/assets/114160956/4add130b-1287-4107-b8a5-371ef2931449) I've taken another approach to make it easier to switch users in the GUI. Server address, username and passwords are stored and retrieved to logon as selected by user. Password storage done by keyring. An additional users.json created to store username and server. [gui_mgr.zip](https://github.com/jellyfin/jellyfin/files/14850839/gui_mgr.zip)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#1221