Plugin: diagnostics report, decode counters, and say when the green screen is on - #122
Merged
Merged
Conversation
Crashes already reach us — TestFlight mirrors them into issues — but the failures that matter here are not crashes. Someone whose source sits on "Trying to reach the phone" closes OBS and never says anything, and the status line cannot tell them why, because the reason is thrown away one layer down. So: Tools → LensLink Settings → Copy a diagnostics report. It gathers what a maintainer would otherwise have to ask for over three round trips — plugin and OBS versions, platform, OS version, CPU and machine, the graphics device, plugin settings, and per source the status, device, transport, decoded totals, latency and which decode pipeline engaged. It carries no video, no audio and nothing personal, and says so at the top. The part that is new information rather than a convenience: tcp_dial threw its error away, so "not reachable" covered both "nothing was listening" and "the OS refused to let us try". Those have opposite fixes and looked identical. The error is now kept per source and reported with its meaning — ECONNREFUSED means the app is closed; EPERM on macOS means OBS has not been granted Local Network access, which is a plausible and otherwise invisible cause of "it just doesn't work on my Mac". Two surfaces, because Qt is not everywhere: a button in the settings dialog that copies and logs, and GET /api/diagnostics on the browser panel for `curl` and for builds without the frontend UI. The report also goes to the OBS log, so an uploaded log carries it whether or not anyone pressed the button. Verified: builds clean on Linux with -Wall -Wextra -Werror, both with and without Qt6 (so both the C and the C++ path compiled); all 54 locale keys resolve; the panel's send loop handles a multi-kilobyte body. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA
"It randomly stops working, and sometimes it's just a green screen" is two
different failures wearing the same face, and the report as written could
not tell them apart.
The plugin already counts what separates them, per connection: video
packets, keyframes, frames the decoder actually produced, decode errors,
and hardware-decode fallbacks. Until now they only reached the log
heartbeat. They are mirrored into the health snapshot once a second, like
the frame and byte totals beside them, and the report prints them together
because the reading is in their relationship:
packets climbing, frames not the link is fine, the decoder stalled —
a picture that froze or went green
neither climbing the link is dead
decode errors climbing the driver is rejecting this stream
hw retries > 0 hardware decode already fell back
The one case worth calling out — packets arrived and nothing decoded — is
spelled out in the report rather than left as arithmetic.
Also names the decoder in use (VideoToolbox, D3D11VA, software) and points
at /api/state for the camera's own settings, since a green picture may be
the phone's virtual green screen doing its job on a subject it can no
longer find, which no plugin-side counter can distinguish.
Verified: clean configure-and-build from scratch with -Wall -Wextra
-Werror on both C and C++ paths, Qt6 present so the frontend compiled.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA
Deploying lenslink with
|
| Latest commit: |
7ea42ea
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://5b166880.lenslink.pages.dev |
| Branch Preview URL: | https://claude-diagnostics-report.lenslink.pages.dev |
A user reported the source going green and staying green — through an OBS restart and a phone restart — and gave up on the plugin. That is the exact signature of the virtual green screen working correctly on a subject it cannot find: the phone paints everything that is not a person chroma green, so a lost segmentation (subject out of frame, or a subject-distance cutoff set too tight) makes the whole frame background. The setting lives on the phone, which is why restarting either end changed nothing. Nothing in OBS said so. The status line read "Connected: iPhone — ~60 ms" while the picture was solid green, so the only available conclusion was that the plugin was broken. It now appends "green screen on", and when the keying filter is missing — deleted by the user, which this code respects forever — it says that instead: "green screen on, but nothing is keying it out". Those are different problems and they now read differently. The diagnostics report carries the same fact, and the troubleshooting page gains the symptom, including that it costs the phone real work per frame, which is a plausible half of the same reporter's "starts to lag". No behaviour change: no filter is added, re-added or retuned. The plugin only stops being silent about a setting that explains what the user is looking at. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA
MyNamesEMurray
changed the title
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
2 participants
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.
What & why
Three commits, all aimed at the same failure: something goes wrong, the plugin
knows why, and says nothing.
1. A one-button diagnostics report
Tools → LensLink Settings → Copy a diagnostics report,
GET /api/diagnosticsfor Qt-less builds and scripts, and a copy into the OBS logso an uploaded log carries it either way.
Collects plugin/OBS versions, module architecture, platform and OS version,
machine and CPU, whether OBS is running translated under Rosetta, the
graphics device, plugin settings, and per-source connection state. No video, no
audio, nothing personal — stated at the top, since it's about to be pasted in
public.
tcp_dialalso threw its error away, so "not reachable" covered both nothingwas listening and the OS refused to let us try — opposite fixes, identical
appearance. It's now kept per source and reported with its meaning
(
ECONNREFUSED= app closed;EPERM= macOS Local Network permission denied;EHOSTUNREACH;ETIMEDOUT= often client isolation).2. The decode counters
The plugin already counted video packets, keyframes, frames decoded, decode
errors and hardware-decode fallbacks per connection — but only into the log
heartbeat. They're mirrored into the health snapshot now, because their
relationship is the diagnosis:
3. Say when the green screen is on
A user reported the source going green and staying green through an OBS
restart and a phone restart, then deleted the app. That is the signature of
the virtual green screen working correctly on a subject it can't find: the
phone paints everything that isn't a person chroma green, so a lost
segmentation — subject out of frame, or subject distance set too tight —
makes the whole frame background. The setting lives on the phone, which is
exactly why restarting either end changed nothing.
Nothing in OBS said so. The status read
Connected: iPhone — ~60 mswhile thepicture was solid green, and the only available conclusion was that the plugin
was broken. It now appends "green screen on", or, when the keying filter is
missing — deleted by the user, which this code respects forever — "green
screen on, but nothing is keying it out". Different problems, now different
text.
No behaviour change: no filter is added, re-added or retuned. The plugin
only stops being silent. The report carries the same fact, and the
troubleshooting page gains the symptom — including that the feature costs the
phone real work per frame, which is a plausible half of the same reporter's
"starts to lag".
How it was tested
-Wall -Wextra -Werroron boththe C and C++ paths, with Qt6 installed so
frontend-ui.cppand the newbutton actually compiled. CI covers Windows and macOS.
en-US.ini.send_strloops on partial writes, since this body ismulti-kilobyte.
Not verified from here: the report's text on macOS and Windows (the
sysctland platform branches compile only there), and the green-screen statussuffix against a live phone — this container has no OBS and no device. The
macOS block and the status wording are the two things worth a glance.
Releases
No trailer, so merging cuts a patch release. Worth shipping promptly: the
green-screen status alone turns a "this is broken, I deleted it" into a
one-line explanation.
🤖 Generated with Claude Code
https://claude.ai/code/session_01PSuQicA9NrKWwpgzY6SvhA