This is a nightly release of Vibepollo and contains several bug fixes and may contain new features. Check the commit log for more information.
Windows installer · Linux (Arch x86_64)
Nightly Windows installers are unsigned and include self-signed gamepad components. They may cause false-positive antivirus alerts.
Source: 37d6742f42f4
Since the preceding successfully published nightly Commit log
2.0.2-nightly.d20261103.r.1.b68e810cffa5: compare exact sources.
fix(apps): Show the built-in Virtual Display tile again
Since 2.0.0 the reserved-name filter that hides legacy copies of the
remote controls also hid the built-in Virtual Display app, which Moonlight
shows as "Virtual Desktop". Users coming from Apollo could not launch it
and fell back to Remote Monitor, which always adds an extra screen.
Exempt the built-in UUID from that filter, and make selecting it an
explicit virtual-display request on NVHTTP launch and resume, WebRTC and
Web UI launches, even when the client normally prefers a physical output.
When NVHTTP cannot create the virtual screen, launch and resume now return
503 instead of streaming the physical desktop.
Register the new applet regression test with CTest.
Vibepollo-only: Vibeshine has no built-in Virtual Display app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix(remote): Keep other apps listed while a Remote Monitor is kept
A client that kept a Remote Monitor after leaving its stream was shown
only Resume and Disconnect Monitor. Moonlight caches that list when the
stream ends and reloads it only on a timer, and Disconnect Monitor
completes with a 410 that Moonlight treats as a failed launch, so the
client stayed on the two-tile list until Moonlight was restarted.
List the ordinary configured apps beside the two Monitor controls. Launch
admission is unchanged: an app can start beside the kept Monitor, a
different app is still refused while another one runs, and other Monitor
profiles stay hidden because they conflict until Disconnect Monitor.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit e8e35f07b52a17c5d9bb2dddf437f26001c7b378)
fix(apps): Keep the Virtual Display target when resuming from a Resume tile
A synthetic Resume tile carries its own app id, so resume() skips seeding
the running app's settings. For the built-in Virtual Display that meant no
virtual screen was requested, and the new create-failure check then
answered 503 for a screen that was never asked for. Apply the built-in
Virtual Display policy from the running app on every resume.
Vibepollo-only: Vibeshine has no built-in Virtual Display app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix(apps): Start Virtual Display on the existing display instead of failing
A launch or resume must never fail while the stream can still start. When
the built-in Virtual Display could not create its own screen, NVHTTP
launch and resume answered 503 even though the stream could start on the
existing display, as Apollo did.
Start the stream on the existing display, log the reason on the host, and
send the client a virtual_display_unavailable warning code on the
successful response. An earlier warning code keeps precedence, because
clients accept only one per response.
Vibepollo-only: Vibeshine has no built-in Virtual Display app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(stream): Send a readable message with client warnings
Client warnings carried only a code, so a client could show text only for
codes it already knew, and every new warning needed a client release.
Add add_client_warning(), which puts the code and a plain-text
clientWarningMessage on a successful launch or resume response. Clients
that recognize the code can still use their own translated text; others can
show the message as-is, and clients that know neither ignore both. A
warning never changes whether the stream starts. The existing
virtual-display-disabled warning now sends its message too, and the first
warning added to a response still wins.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 683bb8e171c3a4aed8aaac2714d951bcd8af0ff9)
fix(apps): Explain the Virtual Display fallback to the client
When the built-in Virtual Display starts on the existing display because
its own screen could not be created, send the reason through
add_client_warning() as well as the virtual_display_unavailable code. A
client that shows host messages now explains why the stream shows the
existing display; other clients ignore the warning and stream as before.
Vibepollo-only: Vibeshine has no built-in Virtual Display app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix(stream): Keep client warning messages safe for every client
Remove the control characters XML 1.0 forbids before sending a warning
message, so a strict client cannot reject the whole launch or resume
response because of one. Tabs and carriage returns become spaces and line
breaks are kept. Leave out a message longer than 512 UTF-8 bytes rather
than send text clients would drop; the warning code is still sent.
Document clientWarningMessage beside clientWarning in architecture.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 43cf27252a205221a295126a5fcd9ad87ba9c914)
docs: Describe the Virtual Display fallback warning
Note in architecture.md that Vibepollo sends virtual_display_unavailable
when the built-in Virtual Display starts on the existing display, and that
launch and resume still succeed.
Vibepollo-only: Vibeshine has no built-in Virtual Display app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fix(audio): Preserve contiguous WASAPI samples across timestamp jitter
Preserve consecutive WASAPI loopback samples on the device-frame timeline so timestamp jitter does not insert silence or overwrite audio. Reanchor on capture gaps, discontinuities, and larger clock offsets.
Refs: Nonary/Vibepollo#703
(cherry picked from commit 062d0ac0291bfe82f98bd59962821eac3155e6d4)