How often should I have to reauthenticate?

I am running Photostructure v1.1.0 in docker-compose.

I haven’t quite figured out replication steps, but I’ve noticed that it has reverted to Lite from Plus a few times. I’ve unauthenticated and it’s fine, but I’m wondering if this is expected, or if there’s some license file that isn’t being saved in a volume so when my container restarts, I have to authenticate, or… something?

Related to this–I’ve read that copying and organizing files on import is a subscriber-only feature. It’s possible I’ve done sync/import stuff when Photostructure thought it was unsubscribed. I want to make sure that all the files in my library have a file copy in the library. (I don’t know if this is clear… sorry!) Is there a way I can check that? Is there a way I can tell Photostructure to check that?


Oof, apologies!

No: I tried to make licensing as transparent as possible–I don’t want to piss off my subscribers!

Once you establish your library with a PLUS license, it should “stick” (and even automatically renew!).

Another user (on UnRAID, not docker) had seen this issue back in September. I made a change (which will be in v2.1, which is not released yet), that should address this bug.

The license file is actually stored in both the library ($libraryDir/.photostructure/licenses) and in the system configuration directory (/ps/config/licenses on docker, or ~/.config/PhotoStructure/licenses on linux), so if you use multiple libraries, the second (and Nth) libraries will already have an active license.

PhotoStructure looks at all licenses in both directories and uses the “best” still-current license. You can use ./photostructure info --plan to get details about which license it’s picking, and the details of the license.

In any event, this should all be transparent to you…

Yes: and I only realized the issue that you described after I shipped v1.1. sync in v2.1 detects if a license is newly activated, and ensures all unique files are properly copied (even if they were synced before with a LITE license).

Yes, but it’s via the command-line. There are a bunch of scenarios with solutions here:

If you have a different question you want me to cook up a script for, please ask: I’m happy to add to that page.

Also: if you want to make sure a specific directory is in sync, you can always shell into your container and run a sync command:

docker exec -it name_of_photostructure_container sh
./photostructure sync /path/in/container/to/directory --force --verbose

The --force bit tells PhotoStructure not to skip over files that seem like they are in sync already (by looking at the mtime and size of the file).

Thanks for the quick response!

Let me know if you think logs or increasing my logging verbosity would be helpful. If you’ve got it, I don’t want to take up your time. This doesn’t seem like an emergency to me and I can wait patiently for 2.1 :slight_smile:

I’ll do a full sync and likely a rebuild once 2.0 or 2.1 lands, so this is moot and really just for edification’s sake, but I ran

./photostructure list --where "Asset.shown=1 AND AssetFile.shown=1" | grep -v ^/ps/library/ # get primary photos not in my library at /ps/library

and got no output, which seems like maybe I didn’t do any import-y things while it was in Lite mode.

I ran the other direction, to get the list of “duplicate variant filenames for each asset”: ./photostructure list --where "Asset.shown=1 AND AssetFile.shown=0", and a good number of them are in /ps/library. I am a bit unsure of what would cause that–is that things like importing a raw as well as a jpg of that raw, so Photostructure would copy both in, but then mark them as the same underlying asset due to image similarity of the two files?

(As an aside, the level of support far, far exceeds what I would expect from how much Photostructure costs.)

PhotoStructure is fine with existing files already being in your originalsDir (which defaults to your library directory, /ps/library). If you bind-mounted a directory with photos and videos in it already, I’d expect those results.

If that’s not the case, we can dig deeper.