The run log
When you run a Multi Job batch, ARTGTO writes a plain-text log of every board it attempts. The log tells you exactly what solved, what fell back to a smaller representation, and what failed — and why.
Where to find it
Each batch run creates a timestamped .txt file in:
%APPDATA%\artgto\job-logs\Files are named run-YYYYMMDD-HHMMSS.txt, one per batch run. They accumulate on disk, so you can review past runs at any time.
Inside the app, the Log sub-tab in the Jobs view shows the contents of the most recent run log. You do not need to open the file manually — but you can, if you prefer a text editor.
Reading the log
The log opens with a header line showing the date, the number of jobs, and the number of boards queued. After that, each board gets one timestamped line. The status tag tells you the outcome:
SOLVED
The board solved at full precision within the iteration and memory budget. Nothing to do — this is the happy path.
SOLVED (16-bit fallback)
The board would not fit in RAM at full (32-bit) precision, so the memory guard automatically switched it to 16-bit compressed storage. The solve completed and the result is usable. Accuracy is very slightly reduced on tough, polarized boards, but for most spots the difference is negligible.
SOLVED (river buckets @ N)
The board did not fit even with 16-bit compression. The solver grouped similar-strength river hands into N shared buckets so the spot could solve at all. Flop and turn keep full per-hand detail, and all showdown math stays exact — only river play is approximated. The number after @ is the bucket count; lower means coarser grouping.
This only happens when the Low-memory fallback option is enabled (it is on by default). If you would rather have oversized boards fail than solve with reduced river detail, uncheck that option.
FAILED
The board did not solve. The rest of the line gives the reason — for example, the spot exceeded available RAM even with all fallbacks, or a range was empty. Common reasons:
- Memory: the spot is too large for your machine. Try enabling
16-bit compressand/orLow-memory fallback, or reduce the raise cap / stack depth. - Empty range: one side has zero combos on that board. Check your range files.
Re-running failures
Failed boards do not need special handling. Fix the underlying cause (free up RAM, adjust settings, correct ranges), then re-run the same Multi Job batch. With Skip already solved enabled (the default), the runner skips every board that already has a .art file on disk and only re-attempts the ones that are missing — including the ones that failed last time.
End-of-run summary
At the bottom of each log file you will see a summary line:
run finished: 3 job(s), 142 solved, 2 failed, 847.3sThis gives you a quick pass/fail count without scrolling through every board.
Where to go next
- Library & batch export — exporting your solved library for the viewer.
- Troubleshooting & FAQ — what to do when boards fail or the app runs out of memory.