WebRTC fails

[rsemp]

I’m using the latest refreshed native-amf-20260709-3 build. The first log line confirms:

Vibepollo version: 1.18.0-beta.4 commit: cc9fdcf

WebRTC fails immediately with:

[2026-07-10 09:53:34.566]: Debug: WebRTC: create session request received
[2026-07-10 09:53:36.696]: Debug: WebRTC: create_session exit id=1D0C96A4-4CB6-EE2C-D318-F0DE709C9740
[2026-07-10 09:53:37.137]: Debug: WebRTC: session created id=1D0C96A4-4CB6-EE2C-D318-F0DE709C9740
[2026-07-10 09:53:37.172]: Error: WebRTC: support is disabled at build time
[2026-07-10 09:53:37.186]: Debug: WebRTC: close_session exit id=1D0C96A4-4CB6-EE2C-D318-F0DE709C9740

The UI exposes the WebRTC Stream page and the host appears to prepare a virtual display, audio sink, WGC capture and H.264 AMF encoder before closing the session.

Is WebRTC intentionally disabled in this Windows tester build, or is this an unintended build/package configuration issue? The release notes mention native AMD AMF / WGC recovery testing, but I could not see anything saying WebRTC is disabled.

I also noticed encode loop logs continue after the WebRTC close_session line, so there may be lingering capture/encoder state after the failed WebRTC attempt.

Originally posted by @rsemp in #295 (comment)

[Nonary]

This has been fixed.

On a build compiled without WebRTC support, the WebRTC page was still reachable and starting a session appeared to work: the host launched the application, created a virtual display, set up an audio sink and initialised capture and the encoder, and only then failed with WebRTC: support is disabled at build time. That also explains the encode-loop activity you saw continuing after the session closed - real capture had been started for a session that could never work.

The request is now rejected immediately after authentication, before any application, display, audio or encoder state is created, and returns a clear error instead of failing partway through setup. Nothing is allocated and nothing is left running.

Thanks @rsemp for the report - the log excerpt showing setup completing before the failure is what made the ordering problem obvious.

This will be included in the next release.

---

This comment was AI generated, but has been peer reviewed by the repository owner.

[github-actions]

This issue has been resolved and will be fixed in the next release. A follow-up comment will be added here once that release is published.

[github-actions]

This issue has been fixed in the latest release, v1.18.3-beta.7. Closing this issue now that the release containing the fix is available.