osn 0.26.28 + #5941 + #5943 #5953
Merged
Merged
Conversation
osn::Video::set previously swallowed SetVideoContext errors, so a failed GPU init at startup left this.contexts[display] looking valid to JS even though libobs canvas->mix was NULL -- silently producing the streaming-start crash filed in Sentry. With osn-node now throwing on IPC failure, wrap the throwing setters in try/catch, tear down the partial context, and emit a new videoContextError subject so UI consumers can gate streaming / recording start on it and show a clear graphics-device error. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
cleanUpSocketConnection now calls func_reset_device after disconnecting the socket, so the singleton MediaSoupTransceiver in mediasoup-connector is fully torn down and rebuilt between Collab Cam sessions instead of accumulating stale device/factory/transport state across reconnects. Pairs with the C++ change in streamlabs/mediasoup-connector#37, which adds the func_reset_device proc and makes LoadDevice idempotent. Two SLD 1.20.9 support tickets ("Guests on Collab Cam are disconnecting after a few minutes") traced back to that drift; resetting on full feature teardown (not on every transient socket reconnect) is the conservative trigger that avoids churn during normal network blips. The new proc is a no-op against pre-fix DLLs (unknown proc names are ignored by the OBS proc handler), so this change is safe to ship ahead of the obs-studio-node bump. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
BundleMonFiles added (4)
Total files change +12.59MB Final result: ✅ View report in BundleMon website ➡️ |
VideoSettingsService.migrateSettings first-time branch reads `.legacySettings` off a freshly created IVideo. On a clean profile (no basic.ini, no autoconfig yet) both `.legacySettings` and `.video` come back zero-initialized. Pushing those zeros back via `.video = .legacySettings` calls osn-server's SetVideoContext with base/output dimensions of 0; obs_set_video_info rejects that and returns OBS_VIDEO_INVALID_PARAM. osn 0.26.28 now propagates the resulting ErrorCode::Error to JS where it was previously dropped, so the first-boot path that used to be silently fixed by a later autoconfig step now throws and tears the whole video context init down. Add a horizontalDisplayData default next to the existing verticalDisplayData and use it as the seed when legacy reads back zero dims. Real settings still land on the context via the regular autoconfig / scene-collection load path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1080p as the placeholder biased two things: it briefly persisted "1920x1080 base, 1280x720 output" into the dual-output profile before autoconfig got a chance to detect the real monitor, and the non-1:1 ratio is an opinionated downscale choice for what should be a neutral filler. 1280x720 base + 1280x720 output (1:1) is the OBS-conventional fresh-profile starting point, matches what osn-server already initializes its first canvas to (see osn log line ~24), and gets overwritten by autoconfig within seconds on a real user's first launch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
gettinToasty
approved these changes
May 29, 2026
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Draft — not for review/merge. Pushed to see how the three changes behave together on CI.
Bundles three open PRs onto a single branch so we can run CI once and see how they interact, particularly around the IPC-error-propagation behavior change in osn 0.26.28.
Cherry-picks (in this order)
surface video-context init failures so UI can gate streaming #5941 —
surface video-context init failures from establishVideoContextDesktop-side handling for the new osn behavior: wraps the now-throwing
IVideosetters in try/catch, tears down the partial context, and emits avideoContextErrorsubject so UI consumers can gate streaming/recording start.Collab Cam: reset native transceiver on feature teardown #5943 —
Collab Cam: reset native transceiver on feature teardownCalls
func_reset_deviceon Collab Cam teardown so the singletonMediaSoupTransceiverin mediasoup-connector is fully rebuilt between sessions instead of accumulating stale state.Update obs-studio-node to v0.26.28 #5951 —
Update obs-studio-node to v0.26.28Pulls in osn 0.26.28, which includes the canvas-video-pipeline streaming-crash fix and the
osn::Video::setValidateResponsechange that propagates previously-swallowedSetVideoContexterrors to the JS layer.Why bundle
PR #5951 alone reproduces a cascade in webdriver CI: a previously-silent
SetVideoContextfailure duringVideoSettingsService.establishVideoContextnow throwsIPC received error code 1, leaving the horizontal video context half-initialized, after whichPerformanceService.skippedFramesthrowscode 4(NotFound), recording stops with code -4, etc. #5941 is the desktop-side fix for exactly that scenario, so running it together with #5951 is the meaningful CI signal. #5943 is along for the ride to validate the Collab Cam reset path on the same osn bump.Source PRs