Browsing and search
Avichive offers several ways into the same archive: original folders, file categories, typed media views, exact-content duplicates and curated life eras. Each answers a different question. Folder browsing shows where files were found; media filters narrow recorded properties; era pages collect items with explicit contextual membership.
The behavior described here is supported by application source inspected on October 13, 2026, at revision e76e74c. This is not a fresh measurement of production coverage or search performance. Missing metadata and unprepared previews remain possible.
Start with the original folders
The folder browser preserves historical locations. It reads precomputed directory totals and child relationships rather than rebuilding recursive statistics from millions of file rows for every page. The direct file list still comes from the scanner catalog, with category filters and filename ordering. Folder browser (app/controllers/browse_controller.rb:14).
For example, an invented Backups/Laptop-2010/Projects folder can reveal both personal source files and installed dependencies. The folder is useful context, but it is not a promise that everything beneath it belongs to one project or deserves the same curation decision. Precomputed statistics are navigation aids, not AI descriptions of folder meaning.
Search names, then narrow the evidence
The global search uses PostgreSQL trigram matching against filenames. Queries need at least three characters. By default, results are ordered by filename similarity; size ordering and category filtering are also available. The application avoids an expensive total-result count and presents previous/next pagination with up to 100 results per page. Search implementation (app/controllers/search_controller.rb:2).
A search for proposal can help find a similarly named file. It does not establish what that file says. This search is not full-document text retrieval, OCR search or semantic search, and path matching is not part of this global filename query. That distinction matters when a useful document has an uninformative name: its discovery may depend on folder context, type filters or curation instead.
Use the view suited to the material
Dedicated photo, video, audio and document records make media-specific metadata available without changing scanner evidence. Document browsing supports size, extension, document type, backup status and exact content hash. Its default view selects canonical copies, with an option to show all copies; detail pages expose duplicates and original availability. Document controls (app/controllers/documents_controller.rb:14).
Canonical browsing reduces repetition while preserving access to provenance. Three historical copies of an identical document do not become three different works. Conversely, two revisions with different bytes have different content identities even if their names match. See content identity and duplicates.
Browse within a life era
A named era page combines included content across media types. Its search is a literal substring match on canonical path or content hash, scoped to that era. Type, capture year, GPS availability, size and sort controls refine the same membership set. Another era’s membership does not add unrelated results. Unknown capture dates have their own category rather than inheriting the era’s years. Era browser specification (docs/LIFE_ERAS.md:17).
A drawer shows metadata and available previews. Preparing a missing photo or video preview explicitly queues processing; the era drawer limits preparation to originals no larger than 2 GiB. A missing preview remains a visible item rather than silently disappearing. Preview preparation (app/controllers/era_files_controller.rb:13).
These tools complement one another. Names and folders offer discovery; hashes connect copies; recorded metadata supplies filters; life eras add curated context. File analysis helps interpret uncertain material, while media processing explains how preserved bytes become browser-ready images and video.