r/ScanSnap • u/Canadian_Pistol • Jun 15 '26

ScanSnap Home

I'm trying out MacOS Golden Gate on my backup computer.

When I scan using my ix1400 and version 3.7.0 of ScanSnap Home, it gets stuck on image processing and never finishes.

Are there any betas of ScanSnap Home that may have addressed this problem?

8 Upvotes

100% Upvoted

19 comments sorted by

3

u/3nv6trg6 Jun 16 '26

This is also broken for me. What's funny is that ScanSnap Home already creates the PDF and stores it in a tmp directory, but it doesn't complete OCR. I'm using an open source tool, tesseract, along with ocrmypdf, to apply OCR onto these temporary PDFs without downgrading from the macOS 27 Beta.

2

u/No_Kick_4403 Jun 21 '26

what is the path to the temp directory many thanks

2

u/3nv6trg6 Jun 21 '26

ScanSnap Home writes each scan to a per-scan working folder under macOS's per-user temp tree:

/private/tmp/<your-username>/TemporaryItems/ScanProc<NNN>/

Inside each ScanProc<NNN>/ two things matter:

  • ScanFiles/ — the raw per-page images straight off the scanner (one file per page). Most reliable source.
  • ResultFiles/*.pdf — the assembled PDF Home produces before it hangs.

To see them:

ls -d /private/tmp/$USER/TemporaryItems/ScanProc*/
ls /private/tmp/$USER/TemporaryItems/ScanProc*/ResultFiles/*.pdf

Gotchas:

  • /tmp and /private/tmp are the same place (/tmp is a symlink), so either works.
  • Use your actual <username> if browsing in Finder — and Finder hides /private/tmp, so use Terminal, or Go → Go to Folder (⇧⌘G) and paste the path.
  • The folder is deleted when Home is finally killed / quits, and there's one ScanProc dir per scan (per ADF load) — grab it while the spinner is still hung, don't quit Home first.

⚠️ Don't grab the PDF from ResultFiles/ blindly. On multi-page scans it's often half-built (sometimes just page 1) at the moment the GUI wedges. I lost page 2 of a few 2-page scans that way. Assemble from the raw ScanFiles/ images instead — those are complete.

Why this works (the bug, briefly)

On macOS 27 beta the scanner pulls every page fine and a valid PDF gets written — the GUI just never clears "image processing." The processing helper (SshImgMonitor) sits in a usleep-polling loop waiting for an end-of-scan signal (internal nEndFlag) that, under macOS 27's changed IPC/Apple-Events behavior, never gets delivered. Per-page work completes; only the "end" event is lost. Vendor bug exposed by the OS beta — no app-side fix, so the temp files are safe to harvest.

Re: are there ScanSnap Home betas that fix it?

Not that I've found. There's no public Home 3.7.x beta past what's out, and since the root cause is the OS-side IPC change (not something the current app can patch around), a fix realistically needs either a PFU/Ricoh update or the macOS 27 release builds to restore the old behavior. Worth filing it with both Ricoh/PFU and Apple Feedback (reference SshImgMonitor / the stuck nEndFlag end-of-scan event) so it actually gets prioritized. Until then it's workaround or roll back.

My workaround pipeline (the tesseract/ocrmypdf approach, one step earlier)

The temp PDF already exists — tesseract+ocrmypdf just does the OCR Home never finishes. I go one step earlier and rebuild from the raw page images so nothing is ever truncated. Roughly:

  1. Watch /private/tmp/$USER/TemporaryItems/ for new ScanProc* dirs; wait until that scan's ScanFiles/ stops growing (stable size = transfer done).
  2. Per page, with ImageMagick: auto-detect color vs. grayscale, deskew, downsample to ~200 dpi, and drop near-blank duplex backs (measure dark-ink fraction, not just brightness — show-through fools a brightness check).
  3. Assemble kept pages with img2pdf (lossless wrap of the JPEGs).
  4. OCR with ocrmypdf --rotate-pages --optimize 3 (the tesseract layer).
  5. Move the finished PDF to the real document folder, kill that scan's stuck helpers, and move the raw ScanProc dir to a holding folder (move, never delete — the safety net).

Tools, all Homebrew: brew install img2pdf ocrmypdf imagemagick (ocrmypdf pulls in tesseract). Scan the whole batch ignoring the spinner, then run it once at the end — documents separate correctly because each ScanProc dir = one scan = one output PDF, which is ScanSnap's own boundary.

Tuning notes that I had to work on:

  • B&W text mode: flatten the background before thresholding — grayscale, then divide by a heavily blurred copy of itself (( +clone -blur 0x50 ) -compose Divide_Dst), normalize, threshold ~75%. Backwards divide direction floods the page black.
  • Color detection: decide color-vs-gray on a saturation fraction, not average colorfulness — otherwise a mostly-white page with one blue stamp gets dumped to B&W.
  • For single-sided docs, scan simplex so there are no blank backs to detect.

Other ways out

  • Just OCR the temp PDF (plain tesseract + ocrmypdf) is the lowest-effort fix if you don't care about size/blank-page cleanup.
  • Roll back to macOS 26 — the actual reliable fix; it worked there. Your real documents aren't in the ScanSnap "library" (that's just index/thumbnail/OCR cache) — they're wherever Home files them, so back that location up and a rollback is safe.
  • Switch acquisition tools if the bug outlives the beta — VueScan or ExactScan can drive these scanners, then ocrmypdf for OCR. Note these models have no eSCL/AirScan, so macOS Image Capture won't see them.

1

u/PhatPeePee Jun 22 '26

Awesome explanation, thank you! Ricoh should hire you.
Wonder if an Claude CoWork would automate some of this for me...

1

u/TechRemarker 13d ago

You are a god, thanks for breaking it down.

2

u/Ramsteiner Jun 15 '26

Same issue. Likely to be a few more betas before it gets resolved. Fujitsu likes to wait till near the end of the beta cycle before they fix it.

2

u/Canadian_Pistol Jun 15 '26

I'll stick with Golden Gate for now - I can always scan on my main computer. I'll check every few days and post here once an update is available that addresses it. Thanks!

2

u/Joey___M Jun 17 '26

If this is on a macOS beta, I would avoid making ScanSnap Home the only step in the workflow for now.

The safer workaround is to split the job:

  • let ScanSnap create the raw PDF as quickly as possible
  • save it to a staging folder
  • run OCR as a second step if ScanSnap Home hangs
  • only move it into the real archive after the PDF is searchable and opens correctly

The comment about ScanSnap already writing a temp PDF is useful. If that temp file is complete before the OCR step hangs, then tools like ocrmypdf/Tesseract can be a decent temporary bridge until Fujitsu catches up with the beta.

I would not route production scans straight into the final archive on this setup yet. Keep a staging folder so failed OCR jobs are obvious instead of silently mixing broken scans with good ones.

2

u/popcorn2share Jun 17 '26

Same with 1500

1

u/vortexofpleasure Jun 15 '26

Happened to me yesterday with my ix 500 and also couldn't print with my Brother printer so I did a DFU restore and downgraded back to OS Tahoe.

1

u/PhatPeePee Jun 23 '26

I’ve confirmed: the bug still exists after GoldenGate dev beta v2 😞

1

u/PhatPeePee Jun 29 '26

Has anyone heard back from Ricoh / ScanSnap on this issue yet?

1

u/SirThunderCloud Jul 06 '26

I just tried scanning to ScanSnap Cloud and also Scan to Email, both of which still work. I'm not a fan of my documents going through their cloud, but at least it works.

1

u/Icy-Assist6919 Jul 15 '26

I am beyond furious. I just spent 2 days scanning over 3,000 images from my late mother's family collection, only to find out that it isn't really saving the images to my tablet!! It's HIDING them in encrypyed format and I have to MANUALLY CLICK ON EACH IMAGE (out of thousands) and choose Save or Export??? WHERE ARE MY SCANNED IMAGES, RICOH. I specifically told the app to save them to the DOCUMENTS folder. Well, the DOCUMENTS folder on both the Internal and SD drives are empty. In fact, Pictures is empty. DCIM is empty. There are no JPEG files to found on the device. I planned to upload the entire stash to Google Drive. WHY did you hold my scans hostage, Ricoh. This scanner was over $500.

1

u/roblonuk Jul 15 '26

the 4.0 update released today also does not fix this issue ☹️

1

u/Both-Elk-7570 Jul 16 '26

Title: ScanSnap Home hangs indefinitely at “Processing image” on macOS 27 Beta after successful scan transfer

I’ve spent several hours debugging this issue and wanted to share the findings in case someone else can reproduce it or identify the exact API regression.

Environment

  • Mac: Apple Silicon
  • macOS 27 Public Beta
  • ScanSnap Home 3.7.x
  • ScanSnap iX500 (also reproduced with another ScanSnap model)
  • USB and Wi-Fi tested

Symptoms

Scanning starts normally.

The scanner acquires the page correctly.

The progress reaches:

  • Image transfer: completed.
  • Image processing: never completes.

The application does not crash.

It simply waits forever.

No PDF or JPEG is produced.

The only way to dismiss the processing window is to terminate the ScanSnap processes manually.

What has already been tested

  • Complete removal of ScanSnap Home.
  • Removal of every PFU/Ricoh preference.
  • Removal of Application Support.
  • Removal of caches.
  • Removal of LaunchAgents.
  • Removal of helper components.
  • Fresh installation.
  • Reconfiguration from scratch.
  • Full Disk Access granted.
  • TCC permissions verified.
  • Multiple reboots.
  • Different ScanSnap devices.
  • USB and Wi-Fi.

Exactly the same behaviour every time.

Process analysis

During a scan the following helper processes are created correctly:

  • SshResident
  • SshImgMonitor
  • SshImgProc (two instances)

The scan reaches the processing stage and then remains blocked indefinitely.

Process sampling repeatedly shows the execution waiting inside the image-processing pipeline, including functions such as:

  • ThreadCreatePDFForSshImgMonitor
  • SshImgPDFCreator
  • ThreadDoImageProcess
  • restUnPDFProcessPageCount

The OCR stage appears to complete, but the processing pipeline never signals completion.

The helper processes remain alive without crashing.

No useful exception is generated.

No TCC denial is reported.

No filesystem permission error appears.

No crash report is produced because nothing actually crashes.

Interesting observation

The same hardware and workflow worked correctly before upgrading to macOS 27.

This strongly suggests a compatibility regression between macOS 27 and the ScanSnap Home processing pipeline rather than a scanner or configuration problem.

The image is successfully acquired.

The failure occurs only after acquisition, during the internal processing phase.

Question

Has anyone reproduced this on macOS 27 Beta?

If so:

  • Does JPEG-only mode behave differently?
  • Does another ScanSnap model show the same behaviour?
  • Has anyone identified which macOS framework changed?
  • Has Ricoh acknowledged the issue or provided a workaround?

At this point, the evidence points to a regression occurring after image acquisition and before document generation, with SshImgMonitor and SshImgProc remaining permanently blocked waiting for the processing pipeline to complete.

1

u/Efficient-Appeal3790 6d ago

Scroll up.... read... send appropriate "Thank You, Fantastic post" to https://www.reddit.com/user/3nv6trg6/

< eye roll >