I am still new to Photostructure and trying to come up with an ideal configuration. I started with PS on my PC with my legacy photo collection and PS library on my Western Digital (WD) My Cloud Mirror NAS (P:\photos and P:\photostructure). It took two days for the library to process, but it completed. (Interestingly, when I start the PC up again, PS wanted to start the scanning process all over again. Is that normal?)
Now I have PS installed on a Raspberry Pi. The photos are mounted read-only on /mnt/photos (from the same WD NAS) and the PS library is at /mnt/photostructure and the photostructure user has write access.
When I started PS it is starting the scan process all over again and it appears my library is empty.
I suspect this has something to do with the UUID stuff I see mentioned in the documentation.
Ideally, I would like to have the Raspberry PI running the show most of the time, but occasionally use my PC (a relatively old, slow laptop) and my newer MacBook for importing. Is this realistic?
Photostructure libraries are designed to be portable between computer and even different architectures (windows, linux, etc). You just can’t have two instances of PS
running simultaneously against the same library though, so you’ll have to be careful about. See the “caveats” listed in the FAQ below.
As far as an initial scan restarting after a reboot, or the other problem with moving to raspberry pi, no those things are not normal. You might be onto something with the UUID though. Is the a .uuid file in the root of the mounted drives? If not, you can always create it yourself if you don’t want PS to do it for you (and obviously it can’t in readonly). The .uuid file is also mentioned in that same FAQ.
Anything more you’d likely need @mrm to look at logs, you also did not say which version of PS you’re running or architecture (windows app, node or docker)
I noticed in the “About” window that the legacy folder does not have a UUID file and I was trying to figure out how to generate one without providing write access to that drive. Good to know I can create it manually. I was honestly going to read up on that next!
Ideally, PhotoStructure would run just as smoothly on all OSes and editions. In practice, however, platforms offer different performance on the same hardware.
Windows disk I/O is 2-10x slower than on Linux (presumably due to Windows Defender and other windows subsystems), so expect slower imports and consequently slower thumbnail delivery to the web UI. (This isn’t just an artifact of NodeJS: this sort of performance penalty exists even for native file copies and random file access).
MacOS desktop builds may stall/fail when they run through GateKeeper, which can hang subprocesses indefinitely (!!) if the codesigning cache doesn’t validate or can’t contact Apple’s remote validation service.
Know that Raspberry Pi will be (heavily) CPU-constrained. Image and video importing and de-duplication are CPU intensive. Expect 10x+ slower imports on a PI4 compared to a recent desktop CPU, and noticeably slower UI performance, but you’ll only be sipping 5W of power, so it’s a tradeoff you may want to make. More information is here: PhotoStructure | PhotoStructure on Raspberry Pi
FWIW, I run PhotoStructure for my family’s library on an ubuntu box hosted on a 5+year old Intel NUC with a 2TB SSD, and it’s wholly usable and chews ~15W. My AMD 5950x workstation can certainly deliver faster performance, but imports run in the background at night, so that doesn’t bother me.
If your whole library was “automatically organized” onto your external drive, and you mounted that library on your RPi, I would have expected all your thumbnails to show up.
Know that thumbnails live in $library_directory/.photostructure/Previews, so as long as that directory has contents, you should be able to browse your library.
Also know that it’s pretty easy to confuse the volume UUID stuff if you’re using docker: if you don’t bind-mount the external drive at the root into your PhotoStructure container, the URI paths in your library database will all be “missing.”
Absolutely! Just make sure:
as @avdp mentioned, that you don’t have PhotoStructure concurrently open the same library directory (say, via your NAS fileshare)
you’re bind-mounting the same volume mountpoints onto your RPi and your other boxen. In other words, don’t mount smb://nas.local/photos/subdir on your RPi, and \\nas.local\photos on your windows box, as the URIs in your library database won’t match up.
Also: remember that it’s fine to have volumes on one machine that the other machines never see (especially if you’re using automatic organization). When a volume doesn’t seem to be present, PhotoStructure’s import will skip over those URIs.
The Raspberry Pi finished its scanning in supposedly 9 hours (my old Windows laptop had estimated 14 hours for the same collection). Unfortunately, my library is showing up empty. The About page is reporting 0 assets.
@mrm Could this be because nothing new was found (as expected)? Is it related to the blank uuid on the legacy folder structure? Should I just wipe everything and start over?
It could, but the best way to see what’s going on is to check out your library db and debug logs.
You can actually tell if you open up your PhotoStructure library database (using something like SQLiteStudio or SQLite Browser, and check out the uri column in the AssetFile table.
There are 4 flavors of URIs:
Files in your library: those look something like pslib:/2022/2022-12-31/image.jpg
Files on local or remote volumes that we have a volume UUID: psfile://2NMQsMVCK/home/example/image.jpg
Files on remote volumes that we can’t read a .uuid for: psnet:/servername/sharename/path/image.jpg
Files on local volumes that we can’t fetch or read a .uuid for: file:///home/alice/Pictures/image.jpg. Note that on Windows, the backslashes will be forward-slashed, and the drive letter will be in there: file:/C:/My%20Pictures/image.jpg
URIs using pslib: and psfile: should be reliable across platforms. The psnet: scheme requires the server hostname to be stable (which isn’t guaranteed, you could use the IP address, a hostname defined in /etc/hosts, or a .local zeroconf name). The file: scheme relies on the full pathname (which obviously won’t be portable across platforms unless the paths match exactly).
Note that unicode pathnames are normalized to NFC before uriencoding. NFC is used by Windows and Linux. MacOS uses NFD, because macOS thinks different, so PhotoStructure has to do URI lookups with both NFC and NFD to ensure pathnames round-trip.