Log Viewer is the centralized telemetry + troubleshooting panel. It aggregates logs emitted by every major workflow (Ingest, Transcode, Transcribe, Adobe Automate, NLE Utilities, Speed Test, etc.), lets you filter/search them reliably, and exports exactly what you’re looking at to share with support/QC or to attach to a ticket.

​

This is designed for post reality: you don’t want to hunt through hidden folders, and you don’t want the UI to choke on a week of batch jobs.

​

What it’s for (real workflows)

• Audit what happened in a job (copy → verify → proxies → attach) without guessing.

• Quickly isolate errors across mixed toolchains (FFmpeg, AME, CEP bridge, filesystem permissions).

• Provide support/QC with a clean export:

  • “everything in the last 7 days for Adobe Automate,” or

  • “only warnings/errors for Transcode,” or

  • “a single job report grouped by stage.”

​

Unified event stream (live + archived)

Log Viewer reads two sources:

1. Archived logs on disk (loaded at panel open)

2. Live IPC log events emitted by panels and the backend while the app runs

Backend logging is structured around createJobLogger() entries (jobId + stage + level + meta), and the viewer normalizes those into consistent fields for filtering.

​

Structured job logs (JSONL) + legacy text logs

The logging system supports:

• Text logs (.txt) for human scanning (and legacy compatibility)

• Structured job logs (.jsonl) for programmatic analysis

Structured logs are written as JSON Lines (one JSON object per line) per job, named like:
<timestamp>--<jobId>.jsonl
and stored under:
userData/logs/<panel>/...

On read, logs are normalized so “warn/warning/error” levels become consistent status values.

​

Caps to prevent runaway memory and UI freezes

There are two separate limits (this matters):

• Render limit (UI only): defaults to 500 lines displayed, even if the filtered set is larger. If your search returns 10,000 entries, you won’t melt the renderer; you’ll see the first chunk and a notice that export still uses the full filtered set.

• Retention limit (in-memory): defaults to 5000 entries retained in memory to prevent unbounded growth during long sessions.

Both are intentionally independent: you can keep a bigger retention window without rendering everything.

​

Fast search without repeated stringify pain

Each log entry builds a cached lowercase “search blob” so free-text search isn’t re-stringifying large meta objects on every keystroke. The search cache is invalidated only when an entry changes.

​

Filters and display semantics

Log Viewer filters by:

• Date window: Today / Last 7 Days / Custom range

• Tool: ingest, transcode, clone, project-organizer, transcribe, adobe-utilities, nle-utilities, speed-test, comparison, resolution, system

• Severity: “errors only” includes warnings + errors

• System logs toggle (or forced when Tool=system)

• Free-text search across message + detail + meta fields

​

There’s also an Expand Task Details toggle:

• shows “detail/meta” lines under the summary line

• enables line wrapping for readability in long payloads

​

Export (what you see is what you export)

Export writes your filtered set to disk in:

• TXT: plain readable log lines

  • special case: if your filtered set contains exactly one jobId, export becomes a Job Report: header + stage grouping + chronological ordering inside each stage, with a filename that includes panel/jobId/time.

• JSON: array of filtered entries (internal search cache fields stripped)

• CSV: flattened fields with meta JSON stringified (bounded to avoid huge cells)

​

This design avoids the usual trap where “Export” dumps the full archive even though you filtered down to one problem job.

​

Safety and security (important, because logs can be sensitive)

Log Viewer’s disk reads are intentionally constrained:

• The renderer asks the main process to read logs via a dedicated IPC handler.

• The main process rejects any directory outside the app’s logs folder (even if the renderer has approved-roots access elsewhere).

• Reads can be aborted per renderer (if you change filters rapidly or close the panel), preventing stuck I/O and keeping the UI responsive.

​

In other words: Log Viewer can’t be used as a general-purpose filesystem browser.