Repository navigation
Open
Labels
bugSomething isn't workingSomething isn't workingdocumentationImprovements or additions to documentationImprovements or additions to documentation
Description
If you run StratoSort Stack v5.1.2 or an earlier version, this issue lists the problems found and fixed since then, so you can tell whether something you see is a known bug. The fixes are on main and ship in the next release after v5.1.2. Updating to that release is the fix for everything below. Where there is something you can do before then, it is noted.
Pull requests: #96 (clean-PC fixes), #97 (bundled Visual C++ runtime), #99 (review fixes), plus earlier fixes on main since v5.1.2. The full list is in the [Unreleased] section of CHANGELOG.md.
1. Can lose or damage your files
- Organize could overwrite a file when two moves picked the same numbered name. Moving
report.pdfandreport_1.pdfinto a folder that already heldreport.pdfcould put both onreport_1.pdf, and one file was lost. Every mover (organize, single move, Downloads, undo, rollback) now claims a name one at a time. - Find Duplicates' "Send to Trash" also acted on sets you could not see. Sets hidden by raising the related slider were trashed too, using a keeper you had picked earlier. Exact-duplicate sets are now re-hashed from disk before anything is trashed. Before updating: if you used Send to Trash after moving the slider, check your Recycle Bin or Trash. The files went there, not to permanent deletion.
- On case-sensitive macOS volumes, renaming to a different-case name could replace another existing file.
- A batch that listed the same file twice and was rolled back reported that file as moved. Crash recovery could also pick the wrong one of two identical copies.
- A rolled-back batch showed as organized. Restored files now report as not moved, and a failed restore names the file.
- A transient read error at launch could replace the organize and analysis journal with an empty one. A corrupt journal is now kept as a
.corruptcopy instead of being overwritten. - One file held by antivirus or the Windows indexer undid the whole batch. Now only that file fails.
- Other move fixes. A destination folder deleted mid-batch is recreated, a cross-drive move that loses a name race takes the next free name, and a move that landed on a numbered name before a crash is kept in undo and search.
2. Local AI, OCR or embeddings do not work on an installed copy
- On a fresh Windows PC, local AI never starts and nothing says why. All versions. The AI engine needs Microsoft's Visual C++ Redistributable (
MSVCP140.dll,VCRUNTIME140.dll), which a clean Windows install does not have. The log showsNoBinaryFoundErrormany times per launch, and every AI feature fails silently. The next release bundles Microsoft's signed runtime and installs it when missing. It also shows a banner and offers Install now in the app. Before updating: install the runtime yourself from Microsoft's download page (X64 or ARM64 to match your PC), then restart StratoSort. - OCR, image preprocessing, log export and embeddings fail in installed builds. v5.0.0 to v5.1.2. Their background workers could not load their own dependencies once packaged, so they failed on every installed copy while working in development. There is no workaround short of updating.
- The zip build dropped its update status instead of saying it cannot update itself.
3. Search index can lose data or stop saving
- A search index too large to save failed silently. Past about 537 million characters per collection, V8 cannot build the save text (
RangeError: Invalid string length). Every save failed and was retried, and new passages were lost at each restart. It is now reported, the rest still saves, and the log warns at 85% of the limit. - A search index file too large to read was renamed as corrupt. It is now left as it is and never saved over, and an automatic repair can no longer overwrite it.
- A startup vector repair wiped the file's details. Restoring a missing vector replaced the whole entry, so the file lost its name, path, tags and hash in search.
- Libraries over 10,000 files lost stored vectors. Those files were re-embedded on every launch and could drop out of search.
- Half-written index files from a crash or full disk were never cleaned up. Each could be hundreds of MB. Startup now removes old ones.
- Missing vectors were never rebuilt under default settings, and files were marked skipped. Startup repair now re-embeds them from stored text.
- One orphaned file marked the whole index unhealthy and triggered a full rebuild after every analysis.
- Quitting during a save cut the save short. Quitting now waits for it, and a save that did not reach disk is no longer treated as saved.
- A session without the compression library could save over the compressed index and its vectors.
- A file that had finished indexing could be set back to "pending" by the smart-folder or Downloads watcher.
4. Privacy
- "Local only" files could reach a cloud provider through long-document summaries. The map-reduce summary step ignored local-only processing. It now honors it.
- Logs wrote some full folder paths. Only the first Windows path in a log line was shortened, so a move line kept the destination folder in full. A macOS or Linux path was shortened only up to its first space, so folders like
Mobile DocumentsorMedical Recordsappeared in full. Path names in log keys and the home folder's account name could also show. - Logs and exported logs could include API keys or tokens written inside text, including Anthropic keys.
- A provider address with a user name or password in it was accepted and could be repeated in errors. It is now refused.
- The smart-folder and Downloads watchers followed links and junctions out of the watched folder.
5. Slow, stuck or degraded
- A large library started in degraded mode. A slow but working startup was marked degraded at 45 s and its services were shut down. It now keeps going and only warns.
- Loading the search index froze the window, and reading it took about 40 s on a 253 MB index. It now loads on a background thread in about 6 s.
- Vision batches stalled. An image whose vision step failed waited until the 300 s timeout and stored a stub. Documents in the same batch could also become low-confidence stubs.
- The vision model restarted for every image on GPUs with little memory.
- Heavy disk writes during analysis. One search index save could be about 785 MB, and saves repeated through a batch.
- Files added to smart folders while the app was closed were all queued at launch, while the window was still opening.
- Each analyzed file was embedded twice by the watchers.
- Search stopped responding while the keyword index rebuilt, and a new search did not cancel the previous one.
6. Other wrong results
- A settings file or smart-folder list saved with a byte-order mark was treated as corrupt and replaced, which reset settings and dropped smart folders. Notepad can add one. Before updating: avoid editing those files in Notepad.
- Find Duplicates checked only the first 1,000 files.
- Scanned PDFs were read only on the first page, and large CSV files were read whole. Both are now capped, and a partial read is marked in the details.
- Chat told the model keyword matches were 0% relevant, showed a raw fragment when a local answer hit its length limit, and returned a cancelled cloud answer as complete.
- Image analysis could save the prompt's example list as the content type, and title-like phrases were offered as new folder names.
- A memory-budget error or a cancel during audio or video analysis was saved as a low-confidence stub.
- Phase tabs, Alt+arrow keys, dashboard links and the File menu disagreed about which screens were open, so returning users could not reach earlier results.
- The naming convention in Discover and in Settings were separate settings.
- StratoSort showed in "Open with" for PDF, Office, text and Markdown files, but opening a file that way did nothing.
- Restoring settings from a backup filed the default settings as the newest automatic backup.
This issue stays open until the release with these fixes is published. Please comment here if you see one of these problems on that release or later.
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingdocumentationImprovements or additions to documentationImprovements or additions to documentation
Activity
iLevyTate commentedon Nov 10, 2026
More problems found while testing with real files on a 6 GB laptop GPU, all present in v5.1.2 and fixed on
mainfor the next release (#106, #107).Files analyzed more than once, slow progress, duplicate notifications
Batch analysis path failed, falling back to per-file worker poolwithOperation already in progress. It could also leave no memory for the vision model, so an image was read with OCR only. Before updating: stay on Discover until an analysis finishes, and don't press Analyze again while one is running.Slow analysis on GPUs with 6-8 GB
Unloading model {"type":"text"}after everyAnalysis complete.[Whisper] Model evicted under memory pressureafter each one.Weaker results
Display
""like this"").iLevyTate commentedon Nov 10, 2026
More problems found in a review of the analysis path and in further testing on a 6 GB laptop GPU. All are present in v5.1.2 and fixed on
mainfor the next release (#108, #109).Analysis that stops, starts over or shows nothing
After Stop
Progress and status
Memory on small GPUs
Smart-folder watcher
Dates
iLevyTate commentedon Nov 10, 2026
More fixes are on
mainwith #110 (not yet released). The ones a user of v5.1.2 can run into:Known and still open after #110, all on GPUs too small to hold two models: an image arriving in the moment a text model starts loading can still start the vision runtime beside it; an embedding model can stay on the CPU after a failed text load until the next one; a text model larger than the memory budget can unload models that free no GPU memory. Details are in the description of #110.