Scan issues: files Meshory couldn't finish

Updated Aug 21, 2026 · 4 min read

Why a model is missing from your library after a scan: where Meshory lists the files it could not read, why each one failed, and how to retry or ignore them.

A large library rarely scans perfectly. An archive turns out to be damaged, a NAS drops for a second mid-read, a folder refuses permission. None of that should stop the rest of your library being catalogued, so Meshory finishes the scan and records what it could not process. That record lives in Settings, under Scanning, as the first thing on the page.

Why a file ends up on the list

Only work Meshory has already given up on. Every stage retries on its own first, so a network blip that resolves on the second attempt never becomes an issue. A row appears when those bounded retries are exhausted, or when the result is permanent for the file as it stands.

• An archive that is damaged, needs a password, or uses a structure Meshory cannot read
• An archive that indexed fine, but whose password-protected entries were skipped
• A folder Meshory does not have permission to read
• A network source that disconnected while a file was being read, or cloud content that could not be downloaded
• A read that timed out
• A model whose preview, geometry or metadata could not be produced

If a whole source could not be walked through, you get one source-level row reporting how many folders were affected, rather than hundreds of rows for the same underlying problem. A file that was never meant to be indexed is a different matter: see What Meshory indexes if a format is missing rather than failing.

What a row tells you

• The file or folder name, and its location relative to the source
• The stage that failed, such as archive indexing, preview generation or metadata extraction
• A plain-language cause, not an error code
• When it was last attempted, and how many attempts it has had

Rows are grouped by source, the Scanning item in the settings sidebar carries the unresolved count, and the whole list survives closing Settings and restarting the app. Reveal opens the file in your file manager; Copy details puts the path, stage, cause and timestamps on the clipboard.

Retrying

Retry re-runs only the stage that failed and shows its progress step by step, so a preview that failed does not re-index the archive around it. The issue clears the moment that stage succeeds; anything downstream, like thumbnails for a newly readable archive's contents, carries on in the background. Retry all works through the list oldest first, and stays bounded so it cannot saturate a network or cloud source.

Ignoring what you cannot fix

Some rows will never clear. An archive whose entries need a password you do not have, a file in a variant Meshory cannot parse, a folder you have no intention of granting access to. Leaving those on the list forever turns a useful list into noise, so you can ignore them. An ignored file drops out of the issue list, stops counting toward the Scanning badge, and stops appearing in post-scan notices, including when it fails again.

Ignoring is filing, not deleting. Nothing is removed: the occurrence, its history, and its place in an exported log all survive. Ignored files are kept in their own list, so you can see what you have set aside and restore any of it later. Restore puts the file back in front of you if it is still failing, and simply clears the entry if whatever was wrong has since been fixed.

Issues that clear themselves

You do not have to work the list by hand. When a disconnected NAS comes back, the next sweep reads the file and the issue closes on its own, as part of rescanning and watching. Changing the file, deleting it, or removing its source closes it too, and the record is kept as history rather than thrown away. Placeholder files in cloud-synced folders behave the same way once the provider hydrates them.

Names and paths stay on your machine

The list shows real filenames and real paths because it never leaves your computer. Diagnostics keep their existing rules: with name hiding on, they carry only counts of issues by kind, stage and cause, and no names, paths or details. Export issue history is an explicit action that writes your unresolved issues plus the last 30 days of resolved ones to a log in Downloads, and warns you first that the file contains local paths.