Deploy & Operate

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
PathWidthTypical use
GET /api/screenshot/low.pngmax 640 pxWeb Console preview, frequent checks
GET /api/screenshot/high.pngmax 1920 pxManual 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

  1. Open the debug panel → Diagnostics, or use the system tray Create Diagnostic Package action (see System Tray).
  2. Click Create diagnostic package.
  3. Note the saved path shown in the panel (also listed under Paths → Diagnostic packages).
  4. 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.

LevelWhen to check
ERROROperation failed — needs investigation.
CRITICALUnrecoverable error before exit.
WARNMigration, retry, or degraded condition.
INFONormal operations (init, state changes).
DEBUGDetailed 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