@waltwooton @Ramblurr thanks for the feedback!
Would you be OK with PhotoStructure spitting out a CSV with verbose sync results that you could open in Excel/OpenOffice? (I then don’t have to find a high-quality scales-to-million-row html table widget!)
The .CSV would look something like this:
| ts | path | status | details | url |
|---|---|---|---|---|
| 1650930793117 | /opt/photos/ | scanned | found 132 files in 3 child directories | http://localhost:1787/tags/fs/CJKLSD |
| 1650930793827 | /opt/photos/.hidden | skipped | hiddenFilter | |
| 1650930793828 | /opt/photos/path-with-nomedia | skipped | noMediaFilter | |
| 1650930794767 | /opt/photos/invalid.jpeg | skipped | invalid JPEG | |
| 1650930795721 | /opt/photos/prior.CR2 | no-op | already in sync | http://localhost:1787/asset/1234 |
| 1650930795721 | /opt/photos/tiny.jpg | skipped | minDimensionsFilter | |
| 1650930797646 | /opt/photos/new.CR2 | imported | http://localhost:1787/asset/2345 |
Update for what’s implemented in v2.1:
The “ts” column is the millis from 1970-01-01 timestamp when that row was written.
The “path” column is the native path of the directory or file.
The “state” column for directories will be
- “scanning” when initially found
- “skipped” if the directory has .NoMedia or considered “ignorable”
- “timeout” if readdir() failed
- “scanned” if all the contents of the directory were scanned or enqueued.
The “state” column for files will be
- “enqueued” if the file is not already in sync with the library, and why
- “rejected” if the file doesn’t pass library filters
- “new” if the file was newly imported into your library
- “noop” if the file had been previously imported and not changed since
- “synced” if the file had been previously imported, changed, and updated in your library
- “deleted” if the file was determined to be deleted
These reports live in $libraryDir/. photostructure/sync-reports