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>
