Show more import and sync details

Sync status is still pretty opaque in PhotoStructure, and is frequently a cause of frustration for users.

Adding the info tool, library metrics and tag counts were tiny steps to help with this, and I wrote this article to give a bit more context, but the situation is still not OK.

The issue is that getting a browser to render a list with hundreds of thousands filenames is a bit of a trick: but maybe that’s not what’s needed?

A beta user suggested adding, after an import is run, a summary that is displayed showing: # of files imported, # of de-dupes, and # of files not imported. I think that would help, but it still doesn’t really answer the question, “why didn’t my file(s) get imported.”

I think a new “recently imported assets” and “recently updated assets” view (via the search view?) would help to show what did get imported.

I wonder if a “recently skipped” view would help (where it’s not images, but just paths to directories and files along with one or more reasons why they were skipped? This would be the first table-of-text view in PhotoStructure. It’d basically be the last N pathnames that sync visited and decided not to import (along with the filter(s) that caused the file to be passed over).

(I’ve even considered writing to a new “sync-status” SQLite db, that could then just be opened by something like the DB Browser for SQLite, and then no new UI would be needed, but this would really only help advanced users).

So, dear users of PhotoStructure: have you seen a UI that handled this sort of thing gracefully that I should look at? Do you have other ideas I can entertain?

How about a “recently imported assets” and/or “recently skipped assets” page that categories the hundreds of thousands of assets by sync attempt (datetime). So you’d see a list of sync attemps and can click to expand any given one. If there get to be some huge number of sync attempts, maybe they can be further categorized by week or month. And if there are still too many assets within sync attempts, maybe they can be categorized by some commonly-problematic attribute (like assets between 1MB and 5MB, assets between 5MB and 25MB; or photo assets and video assets)?

1 Like

I of course like text reports and things… those are always good, even if just summaries. It gives you a warm and fuzzy to see “100 files processed, 100 files successful” or something.

As a couple of ideas:

Mylio, when it has a long list to present, gives a link in the interface/dialog box and if you click it spawns a separate browser window with a pretty plain (but potentially very, very long) list of paths that had an issue (or whatever). If you are delving into a problem, that is often enough to give a clue, or at least confirm which files didn’t work.

My addition here is that maybe you could use your existing interface. Have another selection criterial (like when, camera, lens, etc.) which is “errors” - I know you couldn’t show the image, but a little “box” with a filename and ability to hover or click on it to get more details. Maybe broken into sections based on directory (so each directory with files which had issues would have a separate section on the screen). I say this with the thought that you already have the infrastructure and code to handle very large displays in this manner.

A simple csv export with the following fields would be sufficient for now:

Source/Pictures/(messy library) file and path
Reason for failure
Size of file
Permissions of file (777/755/500…) and owner
Date of last sync attempt

While it would be super slick to have it in the GUI, maybe just start with a csv report from the GUI and move on from there?

For the current solution on the cli:

I cannot get the find output and the Photostructure list command outputs to work together, none of the files line up full path…it would be good if there were also a wildcard capacity for Photostructure info

./photostructure info */familyphotos/somephoto.jpg

And I’ll add… even when it makes it to the GUI, please allow for exporting the list in some parseable format (csv, Json, txt, something). It’s potentially pretty long and having the ability to (for instance) use it in a script with exiftool or something to fix issues would be handy.