Before I delete 5TB of source images, I’d like to review what was skipped. It seems the only way to review this list is following the guide here.
I’m finding the information ps cli offers disagrees with what it’s offering from the browser.
Here’s an example:
from the browser
from ps list cli
photostructure list | grep -i DSCF2385.JPG
Returns nothing.
from ps info library/2022/11/27/DSCF2385.JPG
This will dump color formatted json of the file’s metadata. note that I had to lowercase library in order for ps to find what I was asking for–the web page capitalizes it for whatever reason.
Because ps list doesn’t return this photo, the implication from the guide is that this photo was missed. It obviously wasn’t since I’m looking at it in the browser and its meta is showing accepted.
In fact, every photo out of the source-album ‘photo-dump’ is omitted. Near as I can tell, this problem eliminates a photostructure-supported way to discover sync failures.
I know version 2.* has a csv buried in the log directory, but I ran into big problems using 2… probably standard alpha bug stuff. Since my collection is over 111,000 photos (with three hours left to sync, too), I nuked & paved and started over at 1.1. I’ll have to wait for those tantalizing features.
If possible, I’d recommend having a full backup of those 5TB of files, perhaps sitting on an offline external drive, rather than deleting it altogether. I’d hate to have you lose anything because PhotoStructure filtered out something unexpected.
Did you typo the filename perhaps? The screenshot is for DSCF2384.JPG
Ugh, sorry for that confusion. I believe I fixed that a while ago–there’s no reference to /ps/Library in the code anymore.
Know that the list tool is trying to make sense of the AssetFile.URI column. PhotoStructure doesn’t store pathnames–instead, it uses 4 different URI “schemes,” listed here: Moving from PC to Raspberry Pi - #6 by mrm
Are you running list from a docker container with the same bind mount configuration? Is there a .uuid file in /var/photo-dump? photostructure info --volumes (available in v2.x builds), as well as the /about page will show you what volumes PhotoStructure is currently aware of.
Did you typo the filename perhaps? The screenshot is for DSCF2384 .JPG
That was indeed a typo in my post, yeah. Ooops!
More importantly, since posting, photostructure list | grep -Ec ‘^/var/photo-dump’ now reports the same count of images as the ps web page–this was rather not the case yesterday.
The only thing that changed was time; ps is still ingesting my heap. Still has two more days to go, even.
Are you running list from a docker container with the same bind mount configuration? Is there a .uuid file in /var/photo-dump ?
Why yes I am! But there’s def a .uuid file in /var/photo-dump.
All in all, I think this problem un-happened overnight. While I can’t be 100% sure that typo didn’t leak into my grep from yesterday, I’m super sure that my grep -c returned nothing. BUT… it seems all magically better now. I’m ok with problems fixing themselves
I’m looking forward to 2.x. I wish I could remember what happened when I tried it… something irreversible. Maybe crashing forever or never synching…
