Reports & Logs

evrExpanse keeps a complete record of every work session. At the end of each session it saves a Session Report — a structured summary of everything that happened — and it continues to write detailed logs for each workflow. Both are accessible from the Reports & Logs window.

The Reports & Logs Window

Open it with ⌘⇧L or from Window → Reports & Logs.

The window has two areas, chosen from the selector at the top:

• Session Reports — one report per work session, in a three-pane layout: the list of sessions on the left, the report in the center, and the log of the selected step on the right.
• Logs — the raw log files, shown as text with per-line color coding. A search field filters the visible lines in real time.

Live interactive mockup — click the sidebar tabs to explore each report type.

Session Reports

A Session Report is a persistent record of a single work session, saved automatically when the session ends. Each report captures the source, the workflows that were planned, and the outcome of each one.

The session list

Each session in the sidebar shows, at a glance:

• a status symbol for the overall outcome — 🟢 completed successfully, ⚠️ completed with exceptions, 🔴 completed with errors, 🟡 cancelled
• the time, and the source volume and folder
• a badge for each planned workflow (Offload, Transcode, Export), colored by its individual outcome
• a shield icon summarizing folder sealing, when sealing was planned — green (sealed), yellow (sealed with exceptions), orange (failed), or grey (planned but not run)

The report

Selecting a session shows its full report in the center pane, with a section for each workflow:

• Offload — one row per destination: files selected, processed, not processed, verified and transferred, with data size, elapsed time and verification status
• Transcode — files transcoded out of the total, codec, and result
• Export Metadata — files exported, active formats
• Folder Sealing — the sealed folders, their MHL type and hash, and the sealing outcome

Sections that were planned but did not run — for example after a cancellation — are shown as N/A — not run, so the report always reflects the full intended composition of the session.

Opening a step's log

Within a report you can click an offload destination, the transcode, the export, or the folder sealing to open its log directly in the right-hand pane. These logs are read from the central repository, so they remain available even after the delivery disk has been disconnected.

Session status

The overall session status reflects what actually happened across all steps:

Folder Sealing states

MHL folder sealing reports three distinct outcomes:

• Sealed — the manifest was created and matches its history
• Sealed with exceptions — the manifest was created, but the tool reported notes against the history (for example, files referenced previously that are now missing). The full detail is in the sealing log.
• Failed — no manifest was produced

Exporting a Session Report

A Session Report can be exported as PDF or HTML from the share button in the toolbar of the Reports & Logs window, with Export as PDF…, Export as HTML…, or the matching Share commands to send it straight on. The button is active whenever a session is selected.

The exported document is not a screenshot of the window. On screen the report stays close to the files on disk, so that what you read matches what the tool wrote; the export is a reworking meant for handover, and presents the same session in the form a client or a post house needs to read.

File Manifest

The clearest difference is in the Offload detail. On screen it shows the Transfer Report as written; the exported document replaces it with a File Manifest — one row per source file, one column per destination.

The words in the destination columns are copied, present for a file already at the destination and verified, recopied, not copied, and not processed for a file the run never reached. When every file on a destination ended the same way, the word is lifted into the column heading — all copied, all present — instead of repeating on every row.

Files that need explaining carry a note under the name: a file written under a generated name because a different file with the same name was already there, a source of zero bytes, or a checksum mismatch the report declares but the comparison cannot confirm — for example a report written by an older version affected by a defect since fixed. Nothing is hidden: where the comparison cannot back the Transfer Report's verdict, the manifest says so and gives the reason.

Below the table, the manifest reconciles what it lists with what the run selected. When a run was cancelled or stopped, the files it never reached are counted and named as such: their state at the destination is unknown, and the document says so rather than leaving the reader to subtract.

The manifest closes with the Transfer Reports it was built from, so the document always points back to its source.

Logs

The Logs area is the evolution of the previous log viewer. It lists four categories in the sidebar, selectable like before:

• Event Log — global timestamped log of all sessions
• Offload Reports — per-session Transfer Reports from Offload
• Tag Reports — per-session reports from Apply Finder Tags
• Zero-Byte Logs — reports from zero-byte file scans

Selecting a file displays its content in the detail pane with per-line color coding — green for success, yellow for warnings, red for errors. A search field filters visible lines in real time.

Transcode, Export and Folder Sealing logs are not listed as separate categories here. They are opened from the corresponding section of a Session Report (see Opening a step's log above).

Log Structure

Each log entry follows this format:

HH:MM:SS - [status emoji] Description of event  

Status indicators used in logs:

Session Header

Every log file opens with a session header:

---------- evrExpanse 7.x.x — macOS:xx.x —  system:CPU model with N cores and N threads —  process started YYYY-MM-DD HH:MM:SS ----------  

Local Logs

Each workflow also writes a local log inside the processed folder, alongside the media.

Offload — a Transfer Report folder at the destination:

DestinationFolder/
 SourceFolderName_offload_report/
   Offload Report - YYYY-MM-DD at HH.MM.SS - SourceFolder - DestVolume - DestFolder.txt

The name carries the source folder and the destination, because a session with several destinations writes one report per destination and they would otherwise differ only by the second they started at. The destination folder is omitted when it repeats the volume name.

Transcode — a uniquely-named log inside the destination's evrE_ folder:

DestinationFolder/  
 SourceFolderName/  
   evrE_SourceFolderName/  
     evrExpanse_YYYYMMDD_HHMMSS_transcode.log  

Export Metadata — a uniquely-named log inside the source's evrE_ folder:

SourceFolderName/  
 evrE_SourceFolderName/  
   evrExpanse_YYYYMMDD_HHMMSS_export.log  

Global Repository

All logs and reports are grouped under a single Logs & Reports folder in Application Support. The table below lists every folder on disk. Items marked (viewer) are browsable from the Logs area; the others are opened from a Session Report or kept as the central, durable copy.

(Full base path: ~/Library/Application Support/EVRapp/evrExpanse/Logs & Reports/)

Session Reports are saved in dated subfolders and named Session YYYY-MM-DD at HH.MM.SS. Event Log files are named Event Log YYYY-MM-DD.log. Tag Reports use the format Tag Report YYYY-MM-DD at HH.MM.SS — VolumeName — FolderName. Transfer Reports and Zero-Byte Reports are named after the source folder and, for transfers, the destination: Offload Report - YYYY-MM-DD at HH.MM.SS - SourceFolder - DestVolume - DestFolder.txt and Zero-Byte Report - YYYY-MM-DD at HH.MM.SS - VolumeName - FolderName.txt. Transcode, Export and MHL logs are saved in dated subfolders with a unique timestamped name.

Offload Log Entries

A typical offload log records:

• Session start and configuration
• Per-file transfer and verification status
• Total files transferred, verified, and failed
• Elapsed time
• MHL generation result if sealing was enabled
• Exit code and description on completion

Transcode Log Entries

A typical transcode log records:

• Session start, codec, and TC Mode configuration
• Per-file transcode start, completion, and duration
• LUT application result if enabled
• Metadata embedding result
• TC time-of-day warnings if CreateDate was unavailable
• Total files transcoded and elapsed time
• Exit code and description on completion

Export Log Entries

A typical export log records:

• Session start, active export formats, and TC Mode
• Per-file metadata extraction result
• TC time-of-day warnings if CreateDate was unavailable
• Per-format file open and close confirmation
• Total files exported and elapsed time
• Exit code and description on completion

Transfer Report

Every offload writes a Transfer Report: a plain-text record of what happened to each file, one
report per destination. A copy is always kept in the global Transfer Reports folder, so the record
survives the delivery disk being disconnected. When Save Transfer Report to Destination is
enabled in Offload Preferences, a second copy is written alongside the media at the destination.

The report opens with a header describing the run:

evrExpanse 7.x.x - macOS:xx.x - system:CPU model with N cores and N threads

-- Offload Summary Report --

Report Format Version: 2

Source Folder: /Volumes/CARD A/A001
Destination Folder: /Volumes/SHUTTLE 01/Day 03/A001

Start Time: 2026-09-09 at 17.31.46
End Time: 2026-09-09 at 17.33.52

Hash Algorithm: xxh64be
Preserve Filename on Checksum Mismatch: Enabled
Exclude Hidden Files: Enabled

Total Files: 64
Processed: 64
Verified: 64
Transferred: 2

Data Transferred: 3328 bytes (3.25 KB)
Transfer Duration: 00:02:06 (126.4 seconds)

Status: 🟢 All files were verified successfully.

Total Files is how many files the run selected. Processed is how many the report names,
Verified how many matched their checksum, and Transferred how many were actually written —
a file already present at the destination and verified is processed and verified, but not
transferred.

The body then records one block per operation:

📎 Source File: /Volumes/CARD A/A001/CLIP/A001C001.mxf
Source size: 8123456789 bytes
Source hash: 3f9c11ab77e0d412
Destination file: /Volumes/SHUTTLE 01/Day 03/A001/CLIP/A001C001.mxf
Destination hash: 3f9c11ab77e0d412
Data transferred: 8123456789 bytes (8.12 GB)
Status: ✅ File successfully copied and verified. Destination checksum matches source.

A block is an operation, not a file. When a file already exists at the destination with
different content and Preserve Filename on Checksum Mismatch is disabled, the report records two
blocks for that file: one describing what was found, one describing what was written under a new
name. The counters above count files, so they will not match the number of blocks in that case.

Status lines use the same indicators throughout:

Apply Finder Tags Reports

After every Apply Finder Tags session, a report is saved locally next to the metadata file and a copy is stored in the global Tag Reports folder.

Local report folder:

MetadataFile_tag_report/  
 Tag Report YYYY-MM-DD at HH.MM.SS — VolumeName — FolderName.log  
 evrE_missing_files_${CSVfileName}_${datelog}.tsv  
 evrE_duplicate_files_DateTime.tsv  

Zero-Byte Logs

Before any session starts, evrExpanse scans the source folder for zero-byte files. When any are found, a report is saved in the global Zero-Byte Logs folder.

Zero-Byte Report - YYYY-MM-DD at HH.MM.SS - VolumeName - FolderName.txt

Report format:

Zero-Byte Files Report — DD Mon YYYY at HH:MM:SS  
Volume: VolumeName  
Folder: FolderName  
Path:   /full/path/to/folder  
Total:  N zero-byte files

/full/path/to/file1.mp4  
/full/path/to/file2.mp4  

When no zero-byte files are found, the report records Total: 0 zero-byte files and No zero-byte files found.