Reach web sockets on the server side

[Protected 86]

I'm looking into what can be done to accomplish session syncing via plugin. I see the web socket is already capable of sending commands to the client with play, seek, etc (or in other words, I expect the various clients to already be set up to accept these commands.). Can a plugin obtain the open client/device websockets in order to send these commands through them? I gave a cursory peek at the user manager and network manager and did not immediately spot how this might be accomplished. Do I need to grab some other manager?

[Luke 42077]

Hi, try ISessionManager.SendMessageCommand, SendMessageToSession, etc.

[Protected 86]

I think I'd mentioned the session manager before/had run into it at some point but in my defense, neither the old nor new documentation explain how to get to it!

[Protected 86]

Why can there be additional users in a single session?

[Luke 42077]

4 hours ago, Protected said:

Why can there be additional users in a single session?

So that playback progress reports apply to all of them.

[Protected 86]

Maybe I wasn't clear with how I asked my question. What I'm wondering is under what practical circumstances a single session would contain multiple distinct users. Shouldn't each user and device have their own session? What's the practical need for a multi-user session?

[Happy2Play 9780]

So if two users are watching content together both profiles watch statuses get updated.  But not sure what clients have it.

 

[Luke 42077]

Yea this is something we stubbed out support for in the server a long time ago, but haven't built the features into Emby apps yet.

[Protected 86]

I understand now, thank you. I think under the circumstances that is not a mechanism I'd want to use then. It's better to control sync on the plugin side, especially since that can easily be extended to work with devices using clients other than the web client (assuming they'll obey the websocket commands).

[Protected 86]

• Is there any event I can use to reliably detect manual seeking or is the correct method to handle TimeUpdate and detect "large" (or negative) position offsets? (syncing position on every time update is too overwhelming, not to mention unnecessary).

I think I'm otherwise correctly syncing (and I see good results in testing for!) the other playback occurences I need:

PlaybackStart => PlayCommand.PlayNow
PlaybackProgress + ProgressEvent.Pause/Unpause => PlaystateCommand.Pause/Unpause (+ ticks)
PlaybackStopped => PlaystateCommand.Stop

 

• These fire, but the GeneralCommand doesn't seem to update the ongoing playback. Maybe I also need to send stop and start? I'll be testing further later.

PlaybackProgress + ProgressEvent.AudioTrackChange/SubtitleTrackChange => GeneralCommand + SetAudioStreamIndex/SetSubtitleStreamIndex (+ index)

 

• Still somewhat in the dark about how information on the contents of playlists and sets of multiple selected items are conveyed by the SessionManager. The PlayRequest message takes a list of ItemIds (internal, database IDs) but the PlaybackStart event only seems to carry one single BaseItem. Doubtless every time I change items using the next/previous buttons in the interface a new PlaybackStart event fires, but it would be nice if I could bootstrap each remote client with the full list of items so they also get the next/previous buttons.

Currently I internally institute the authoring session of the first fired PlaybackStart when a party is idle as the "host" and ignore further playback updates from other sessions until PlaybackStopped (in order to prevent cyclical updates and other sync problems), but for some manual events, like playlist next/previous, it would be cool if any participant could change the video and tranparently "hijack" the hosting role, which does require their client to know what the next video is.

PlaybackStart *does* carry a PlaylistItemIds list of strings. If these are media item guids for the contents of a playlist that is being played back, and are also provided for multiple items played back through checkbox selection (without a playlist) or other aggregate methods, I'll ascertain that in my very next testing session and no more information will be needed.

 

• Currently, multiple open tabs in the same browser and container running the web dashboard (which share the same session ID) will result in duplicate events leading to the compounding synchronization issues I'm trying to avoid (it's the only case resulting in these). Is there a way to distinguish these tabs?

Thanks for the help with this stuff so far, I really appreciate it. To be clear if I'm taking too much of anyone's time, I'm still working on this when I can, even while waiting for responses, and will endeavor to find solutions on my own, but any information helps.

Edited September 9, 2024 by Protected

[Protected 86]

Update for this:

- Seek (position) synchronization: Largely solved (manually), though it was a complicated problem (I'm using pause/unpause tracking and estimation based on event time tracking to maximize accuracy). I'm still seeing some baffling cases of TimeUpdate events carrying position ticks that don't add up which require further investigation later (when the host's position ticks fall too far from expected it triggers a sync action in which the host pauses and attempts to sync with all guests, so this is an undesirable stutter when, as in this case, it's unnecessary).

- Audio track and subtitle track changes: Fixed. The Index argument of the general command was being passed as index (lower case). Emby will not verify the argument and so the error will propagate until the playback info API call is sent a track index of "NaN" and triggers a server side exception not in my code. Hard to figure out!

- Playlist contents: Figured out. PlaylistItemIds always seems to be empty but the information is available in the session's queue contents.

- Distinguishing multiple tabs in the same browser session: I still haven't figured this one out.

There is one more issue I'm not quite sure of. One minute after I send a pause command to a guest session (that is, the session that is being remote controlled), Emby determines that the session has timed out and closes the video player. It doesn't do this to the host session (where the pause originated), which puts both sessions in different states, since the host session can still be unpaused, but the guest session requires a new play command. Can I prevent the guest video player from being closed? Should I be calling Ping manually on the guest session every 30s or so while it's paused?

[Protected 86]

In the end I did successfully solve the time out "problem" using a ping timer. I'm aware this has a negative impact on server resource usage.

I'll publish the source code for this whole thing when it's done so that all may wince at how inefficient it is.