Switching away from Skood and back causes a visible stall, and sometimes yanks playback for everyone else in the room.
Two things happening in public/script.js:
-
The visibilitychange handler (public/script.js:302) fires request_sync on every return to the tab. The server answers with sync_state, and applySync() unconditionally calls loadVideoById() — a full player reload — even when the video hasn't changed and you're only a fraction of a second out. That reload is the lag.
-
That reload then fires a PLAYING state change. suppressEvents is cleared after a fixed 300ms (resetSuppress(), public/script.js:470), but the reload finishes later than that, so onStateChange treats it as a real user action and emits play. Everyone else gets seeked because you changed tabs.
Fix: applySync() should compare against current state — same videoId and drift under a threshold means do nothing, small drift means seekTo(), only reload when the video actually changed. The fixed 300ms suppression window is fragile in general and would be better tied to the player reaching the expected state than to a timer.
Switching away from Skood and back causes a visible stall, and sometimes yanks playback for everyone else in the room.
Two things happening in
public/script.js:The
visibilitychangehandler (public/script.js:302) firesrequest_syncon every return to the tab. The server answers withsync_state, andapplySync()unconditionally callsloadVideoById()— a full player reload — even when the video hasn't changed and you're only a fraction of a second out. That reload is the lag.That reload then fires a PLAYING state change.
suppressEventsis cleared after a fixed 300ms (resetSuppress(),public/script.js:470), but the reload finishes later than that, soonStateChangetreats it as a real user action and emitsplay. Everyone else gets seeked because you changed tabs.Fix:
applySync()should compare against current state — samevideoIdand drift under a threshold means do nothing, small drift meansseekTo(), only reload when the video actually changed. The fixed 300ms suppression window is fragile in general and would be better tied to the player reaching the expected state than to a timer.