Diagnostics
DearScenario Player provides built-in diagnostic tools for remote troubleshooting: screenshots, crash dumps, and diagnostic package collection. These are essential for debugging issues on headless or remote display machines.
Screenshots
The screenshot API is a read-only PNG of the final on-screen composite. One GET returns the image. There is no command, Job, query parameter, or second polling path.
curl http://<player-ip>:18290/api/screenshot/low.png -o low.png
curl http://<player-ip>:18290/api/screenshot/high.png -o high.png| Path | Width | Typical use |
|---|---|---|
GET /api/screenshot/low.png | max 640 px | Web Console preview, frequent checks |
GET /api/screenshot/high.png | max 1920 px | Manual inspection, test-tool visual checks |
Success is Content-Type: image/png with Cache-Control: no-store. One GET
waits up to 3 seconds. If nothing is available in that window, the player
returns the previous cache when it has one, otherwise HTTP 503.
Normal and Maintenance behave the same. Source IP allowlisting still applies. Callers cannot choose size, scene/screen, disk storage, or freshness. The capture includes video, idle background, mask, overlays, calibration, Debug UI, and dialogs.
Screenshots are not a command transaction. To prove a previous fire-and-forget
command took effect, read GET /api/status first, then GET the PNG.
The player does not write HTTP screenshots to disk. Concurrent callers share one capture; low quality is collected at most once per second, high quality at most once every two seconds.
Removed (do not use): the screenshot command, /api/inspection/thumbnail,
and /api/diagnostics/screenshot/latest.png / latest.json.
Crash dumps
When the player crashes, a minidump is generated for post-mortem debugging.
Windows
Minidumps and adjacent JSON metadata are written to:
<exe_dir>\logs\crash-dumps\The crash handler is initialized at startup and captures the call stack, register state, and loaded module list at the point of crash.
Linux / Raspberry Pi
The application crash handler writes signal reports under the active log
directory's crash-dumps/ folder. System core-dump collection can be enabled
separately through ulimit -c or systemd when required.
macOS
The application crash handler uses the active log directory's crash-dumps/
folder. macOS system crash reports, if generated by the OS, are separate.
Diagnostic package
Use a diagnostic package when you need to send support a redacted snapshot of build information, configuration, recent logs, and crash-dump metadata.
Create from the player
- Open the debug panel → Diagnostics, or use the system tray Create Diagnostic Package action (see System Tray).
- Click Create diagnostic package.
- Note the saved path shown in the panel (also listed under Paths → Diagnostic packages).
- Review the archive before sharing it. Known sensitive values are redacted where possible, but treat the package as support-confidential.
What it typically includes
- Build / version information
- Configuration summary (with sensitive fields redacted where possible)
- Application logs
- Metadata for recent crash dumps
The package does not replace live observation—use
Remote Debug or GET /api/screenshot/high.png when you need to see
the current frame.
Log files
Log files are the first stop for troubleshooting. See Logs & Crash Dumps for log file locations, rotation, and custom log paths.
| Level | When to check |
|---|---|
ERROR | Operation failed — needs investigation. |
CRITICAL | Unrecoverable error before exit. |
WARN | Migration, retry, or degraded condition. |
INFO | Normal operations (init, state changes). |
DEBUG | Detailed diagnostic info (dev mode). |
Remote Debug
For live visual debugging, the Remote Debug WebSocket streams the ImGui debug overlay to a browser. This is complementary to screenshots — use Remote Debug for live observation and screenshots for point-in-time captures.
See Remote Debug for details.
Previous / Next
- Previous: Watchdog
- Next: Logs & Crash Dumps

