Per user feedback: no separate control panel, no chat. Found that
PluginPageInfo has EnableInUserMenu/EnableInMainMenu (confirmed via
reflection on the real MediaBrowser.Model assembly, plus an Emby
community thread showing another plugin using EnableInUserMenu=true)
- a real, if barely documented, way to surface a plugin page to
regular users, not just admins, through the exact same
IHasWebPages/GetPages() mechanism as the admin settings page.
- Plugin.cs now registers a second page (partyPage.html) with
EnableInUserMenu=true + EnableInMainMenu=true
- partyPage.html replaces the old standalone control panel: no login
form, it runs inside the already-authenticated Emby web client and
calls the REST API via the global ApiClient
- Removed web/control-panel/ (the standalone app, its own login flow,
and the custom GET /WatchParty/app* static file routes in
WatchPartyService.cs) - no longer needed
- docs/architecture.md and README.md updated: the new mechanism, and
the honest limitation that comes with it (reaches Web/Electron
clients, not official mobile/TV apps - those allowlist plugin pages
client-side)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Installed .NET 8 SDK (per-user, winget needed admin elevation this
machine doesn't have) and restored the real MediaBrowser.Server.Core /
MediaBrowser.Common packages, then fixed everything the compiler and
a bit of reflection surfaced:
- PlaybackProgressEventArgs/PlaybackStopEventArgs are in
MediaBrowser.Controller.Library, not ...Session
- IAuthorizationContext/AuthorizationInfo are in MediaBrowser.Controller.Net
- Item/user/session ids (SessionInfo.Id/UserId, BaseItemDto.Id) are plain
string on this SDK version, not Guid - Party/PartyMember updated
accordingly (Party.Id stays a Guid; it's minted by this plugin, not Emby)
- Reading the calling user needed an extra step:
IAuthorizationContext.GetAuthorizationInfo(Request).UserId is a `long`
(internal row id); .User.Id is the one matching SessionInfo.UserId,
but it's a Guid so it's reformatted with .ToString("N")
docs/architecture.md's "Assumptions to verify" now reflects what was
actually confirmed vs. what's still only compile-checked (HTTP status
codes, content-type headers, the JS auth header format, the dashboard
config page) pending a run against a real server.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Design: coordinate parties on top of Emby's existing session
remote-control commands (SendPlaystateCommand) rather than building a
new player. Each member keeps their own Emby app/controls; the server
periodically corrects drift and mirrors pause/unpause against one
reference member's reported position.
- src/WatchParty: plugin skeleton (BasePlugin, IServerEntryPoint,
IService/[Route] API, in-memory party store, drift-correction loop)
- web/control-panel: plain HTML/JS/CSS companion page to create/join
parties and resync, served by the plugin itself
- docs/architecture.md: full design, sources consulted, and an
explicit list of SDK details that still need verifying against a
real build (no .NET SDK / Emby SDK assemblies available in this
environment to compile against)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
