Diagnose stalled processing and export

What you will do

Use Export and Render History to decide whether work is queued, in progress, or contains a failed photograph. You will preserve the visible failure details and identify the affected photograph before changing anything, then verify recovery in both the history and the saved JPEG.

The steps were verified on Windows in Arams 1.10.2 with the interface set to English. The verification run included one active local export, a second queued export, and a third export containing one failed photograph. Recovery was accepted only after the restarted task completed and the transferred full-resolution JPEG was opened and inspected independently.

Before you start

• Sign in on Windows and use the English interface.
• Work in a disposable practice project. Import the full-resolution maxine-01.jpg and maxine-02.jpg fixtures; both prepared JPEGs are 6064 × 4040 pixels. Do not resize them for face processing.
• Keep the source photographs unchanged. Use a new export subfolder for each attempt so that an older file cannot be mistaken for the result of the current task.
• Do not clear the history while diagnosing a problem. Its status, message, mode, photo count, and filename are evidence you may need.

The verification scenario uses an already activated local tool for a two-photo export, queues a second export behind it, and makes only a disposable source copy temporarily unavailable for the failed export. It does not purchase or activate a plugin, use cloud credits, change the account, or overwrite an original.

Distinguish queued, running, and failed tasks

1. Open the project in which processing appears to have stopped.
2. Click the history icon above the photographs. Its verified tooltip is Export and Render History.
3. Find the newest task and read its status instead of judging it only by the amount of time that has passed. The verified active states are Queued and In progress.
4. Record the task type, mode, progress, photo count, and elapsed time shown on the same task card.

A queued task is waiting behind work already in progress. An in-progress task is the one Arams is currently processing. The first verified snapshot caught the active task at 0%. A later snapshot showed the second task as Queued at 0% while the first task was In progress at 49%. A photograph listed under Failed to export is different: waiting longer does not establish recovery.

The active task is marked In progress; record its progress and elapsed time before attempting recovery. Arams 1.10.2 · Windows · English

Queued distinguishes a waiting task from the task already marked In progress. Arams 1.10.2 · Windows · English

Read the error and identify the affected file

1. Leave the failed task in the history.
2. Expand Failed to export and inspect the failed photograph before taking a recovery action. The reviewed history showed a red error indicator, the photograph thumbnail, and a restart button, but no filename or explanatory message.
3. Compare the displayed photograph and failed count with the files selected for that operation.
4. Record the affected filename, the task type and mode, the destination, and whether the source file is still present at its original path.
5. If the history does not expose a filename, return to the project and compare the selected photograph with the task’s photo count. Report that the filename was inferred from the selection rather than displayed by Arams.

The task card can show Completed and 100% while its expanded details still contain Failed to export. Inspect the expanded photo section; do not treat the task-level percentage alone as proof that every file was written.

The verified example deliberately made only the disposable maxine-02.jpg copy unavailable after import. The failure row did not show its filename or an explanatory message; the selected photograph and one-photo count identified the affected file in this controlled project. Do not generalize this result to network, server, plugin, credit, or corrupt-file failures unless Arams displays evidence for one of those causes.

Failed to export shows one failure even though the task card reads Completed 100%; this view does not display a filename or cause. Arams 1.10.2 · Windows · English

Recover and verify the output

1. Correct only the condition supported by the evidence. In the reviewed missing-source example, restore the disposable JPEG to its original name and path.
2. In Failed to export, click the circular-arrow restart button on that photograph.
3. Keep Export and Render History open and confirm that the task returns to work, then reaches Completed and 100%.
4. Open the newly written file outside Arams. Check that it decodes, shows the expected portrait without blank or corrupt areas, and remains 6064 × 4040 pixels.
5. Confirm that both source JPEGs still match their original files.

In the verified run, the restart created maxine-02-retouched.jpg in the same failure-test subfolder. The transferred review copy was a decodable 6064 × 4040 JPEG showing the expected portrait, and the two source fixture hashes remained unchanged.

After restoring the source and restarting the photograph, the failure is absent from history; the saved JPEG was opened and checked separately. Arams 1.10.2 · Windows · English

Check the result

The history should show the unsuccessful photograph before restart. After restart, the task should show Completed and 100%, with no Failed to export section. The original failure destination should then contain one newly written, decodable JPEG for the affected photograph. The original fixture files should remain present and unchanged.

Treat the output-file check as part of recovery. A status change or 100% indicator alone does not prove that the intended file exists, opens correctly, or came from the latest attempt.

If it still does not work

• The task is waiting: keep the history open long enough to see whether its status advances. Record other active tasks that may be ahead of it; do not delete their records as a diagnostic shortcut.
• The task is running: record its current progress and elapsed time. Do not start repeated exports merely because the percentage remains unchanged during one observation.
• The task failed: preserve the visible error indicator or message, mode, photo count, affected filename if visible, and destination. If Arams does not show a filename or cause, say so instead of inventing one.
• The source file is missing: restore the disposable copy to the path used by the project, then restart the failed photograph from Failed to export. Relinking through an Arams control has not been verified for this chapter.
• The new task completes but no usable file appears: check the destination and filename settings, then open the actual output. Do not report recovery until the JPEG decodes and has the expected dimensions.
• The message names a plugin, network service, account capability, or credits: stop and report that exact message. This missing-source recovery does not establish a remedy for those failures.

Related topics

• Review processing tasks
• Process a photograph locally
• Export photographs and verify saved files
• Import photos