feat(diag): browser-based diagnostics viewer over OSC

[dedicatedbroadcastsolutions]

Prototype of a lightweight alternative to the SFML DIAG window: a small opt-in HTTP+SSE server that mirrors every caspar::diagnostics::graph's text/values/colors/tags into JSON, with no rendering cost on the server.

• GET / - a small <canvas>-based viewer (all rendering client-side)
• GET /snapshot - one-shot JSON for simple polling clients
• GET /events - Server-Sent Events stream for clients that want to subscribe and do their own rendering/processing
• Enabled by default at configuration.diag.default-port (4000), matching how OSC's client is always active; 0 disables it
• Tracks graphs by a stable id (not registry position), shows channel/layer context, renders per-tag severity, and boosts the visibility of dropped/late-frame style series over their (often very dark) SFML colors

Closes #899, #1310 (replaces the SFML DIAG window entirely, so it no longer competes for GPU/desktop resources). Related to #1361 (network-exposed graph stats — done over HTTP/SSE here rather than OSC), #1544 (per-port device labeling — not yet implemented, still channel/layer only), #1139 / #1654 (broader websocket control/monitoring proposals — this is a lighter-weight alternative for the monitoring half), #914 (motivation: avoiding desktop-GUI overhead on the server).

Status: draft. Core/protocol and the full executable build cleanly (confirmed both isolated and end-to-end), but I have not yet run this against a live playout server or exercised it under real load - want to validate the viewer/SSE behavior for real before marking ready for review.

Edit: This has been updated to be OSC instead of HTTP/SSE

[dimitry-ishenko]

As much as I love the idea of ditching the DIAG window, I don't think bolting a web server onto CasparCG Server is the right direction.

I like the idea of spitting out diagnostics through OSC via an opt-in option. That way, people can use their preferred GUIs to show that data in their preferred way. And those who don't use it won't be bothered by it.

I go by the motto "the best code is no code at all", so the more "features" we can strip out of the core Server code, the better. IMHO, of course.

[dedicatedbroadcastsolutions]

Ok, I can shift it towards that direction if we want to do it via OSC. Using a browser with SSE shifts the render off with minimal overhead of serving a basic web page.

Since X11 is going away, I am not sure we can call diag replaced without having a UI for it shipped with the server, but I can make a simple UI that is a separate light weight web server executable that can provide that functionality for those who need it while keeping with your motto for the server core.

[martastain]

I like the idea of spitting out diagnostics through OSC via an opt-in option. That way, people can use their preferred GUIs to > show that data in their preferred way. And those who don't use it won't be bothered by it.

Sending diag info over OSC would be great!

[Julusian]

I think that keeping this to OSC would be best. I had this in mind when doing 8f05ef7, my intention was that using that subscribe could accept an argument to say to include the detailed diag stuff too in some way (unsure how granular that should be)

I can think of 3 different ways I would like to use this data, depending on setup/environment:

• An app which converts it to prometheus/influx or something suitable for analysing in grafana after an issue occurs, or for setting alerts.
• A web app, for simple realtime monitoring of a server
• Maybe a desktop app, but perhaps that could be good enough with the web app version.

So ideally there could be a separate repo(s) in the casparcg github org for these tools. I dont have a particular preference on language for any of this, or whether its one repo with different tools or multiple repos.
One thing to think about early though is that if a desktop and web app are wanted for realtime viewing, being able to share code between them will make that much easier.

[dedicatedbroadcastsolutions]

I have a typescript/electron front end that can be the web and desktop UI for this. I'll update this pr accordingly soon.

[dedicatedbroadcastsolutions]

Pushed an update that drops the embedded HTTP+SSE server/viewer entirely per the discussion above, in favor of broadcasting caspar::diagnostics::graph telemetry over the existing OSC transport:

• core/diagnostics/web_graph → osc_graph: the sink now mirrors each graph into core::monitor::state (diag/<id>/channel, .../layer, .../text, .../value/<name>, .../color/<name>, .../tag/<name>) instead of a JSON blob.
• protocol/osc/client broadcasts this on its own ~40ms cadence, but only to endpoints that have opted in, and only while at least one has - so it costs nothing for anyone not using it.
• Opt-in is per-subscriber: OSC SUBSCRIBE <port> DIAG for AMCP clients, or a <diagnostics>true</diagnostics> flag on a configuration.osc.predefined-clients entry for static subscribers.
• Removed protocol/util/diag_http_server and the configuration.diag section entirely - no more web server/viewer bundled with the core server.

Core, protocol, and the full executable all build cleanly with this change.

The TypeScript/Electron app I mentioned will consume this OSC data directly and is where the actual viewer UI (web + desktop) will live, as a separate project outside this repo.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}