Pending images are not resumed/requeued after processing is stopped, and there is no obvious UI recovery option

[rtho782]

Summary

If image processing is stopped while there are still pending images, those images remain in the database with status = pending, but they are not automatically requeued when processing is started again or when a scan is run.

Newly detected files are processed correctly, but existing pending files just remain stuck as pending unless manually selected and reprocessed through the UI.

This becomes a problem when there are thousands of pending images, as manually selecting and reprocessing them is not practical.

Expected behaviour

After stopping and later restarting processing, A-Eye should either:

1. automatically resume processing existing pending images, or
2. provide a UI button / API action to process all pending images, or
3. requeue pending images when a scan is run.

Actual behaviour

Existing images already known to A-Eye remain in the database as pending, but are not added back into the processing queue.

Once processing is stopped, I cannot see an obvious “scan”, “resume”, “process pending”, or “requeue pending” option in the UI. This means there does not appear to be a practical built-in way to recover from a stopped queue.

Newly detected files are processed correctly, but old pending files remain stuck.

This is especially problematic with very large libraries. In my case the library is around 500,000 photos, so manually selecting pending images and choosing reprocess is not practical.

Reproduction steps

1. Start A-Eye and scan a large photo library.
2. Allow it to queue/process images.
3. Stop processing while many images are still pending.
4. Start processing again or run another scan.
5. Observe that newly detected images process normally.
6. Observe that old pending images remain stuck as pending.
7. Manually selecting some pending images and choosing reprocess does work, but this is not practical for thousands of images.

Suspected cause

It looks like A-Eye has a persistent DB status for images, but the actual worker queue is in-memory.

When processing is stopped, queued work is drained from the in-memory queue, while the corresponding image records remain pending in the database.

On restart/rescan, those pending DB records are not automatically rehydrated into the worker queue.

Workaround

I was able to work around this by repeatedly calling the batch processing endpoint for pending images, for example:

#!/usr/bin/env bash

AEYE="http://YOUR-AEYE-IP:8000"
limit=200

while true; do
  json=$(curl -s "$AEYE/api/images?status=pending&limit=$limit&offset=0")

  ids=$(echo "$json" | jq '[.images[].id]')
  count=$(echo "$ids" | jq 'length')

  if [ "$count" -eq 0 ]; then
    echo "No more pending images found."
    break
  fi

  echo "Enqueuing $count pending images"

  curl -s -X POST "$AEYE/api/images/process-batch" \
    -H "Content-Type: application/json" \
    -d "{\"image_ids\":$ids}" | jq .

  sleep 2
done

This confirms that the pending images themselves are processable; they just are not automatically requeued.

Suggested fix

Add one or more of the following:

• A clear “Resume processing pending images” button.

• A “Process all pending” button.

• An API endpoint to enqueue all images with status = pending.

• Startup logic that automatically requeues pending images.

• Scan/reconcile logic that finds DB records marked pending and adds them back to the worker queue.

• A “reset / clear queue / rescan library” maintenance option.

• Clear UI distinction between:

  - images that are pending in the database, and
  - images that are actually queued in the active worker.
  

[vonhex]

try giving my fork a try I think I fixed this issue, he has yet to pull my changes. https://github.com/vonhex/a-eye its also on Unraid in the community apps.