Photostructure does not seem to be pulling in new files dropped into my source directory. I’m certain that they will come in if I run “restart sync”, but I wanted to provide a troubleshooting opportunity.
There are several photos that were added to the directory a week or more ago. I do not have automatic organization enabled.
Does anybody else have this problem?
You’re on docker on UnRAID, using v1.0.0-beta.9, correct?
What does info --sync-paths say?
docker exec -it PHOTOSTRUCTURE_CONTAINER_NAME sh
./photostructure info --sync-paths
Yes.
/ps/app # ./photostructure info --sync-paths
[
{
uri: 'psfile://3HZ4UtEZv/',
lastUpdatedAt: 1624126548764,
lastCompletedAt: 1624126548764,
lastStartedAt: 1624126328205,
nativePath: '/photos/'
},
{
uri: 'pslib:/',
lastUpdatedAt: 1624126548852,
lastCompletedAt: 1624126548837,
lastStartedAt: 1624126548777,
nativePath: '/ps/library'
}
]
Ugh I need to convert those timestamps to something reasonable.
I also experience this on all v1 betas, have reconciled that I just need to manually click Restart Sync whenever I want it to find new photos, then they start showing up about 5min later
I ran docker exec -it PHOTOSTRUCTURE_CONTAINER_NAME sh ./photostructure info --sync-paths and got:
./photostructure: line 3: /bin: Permission denied
./photostructure: line 4: CHANGELOG.md: not found
./photostructure: line 5: can't open https://photostructure.com/eula: no such file
./photostructure: line 9: syntax error: unexpected "("
But when I run docker exec -it photostructure sh I am brought into the container’s shell, and then I can run /ps/app # ./photostructure info --sync-paths and I get actual results:
[
{
uri: 'psfile://2VheogVek/',
lastUpdatedAt: 1625097867603,
lastCompletedAt: 1625097673892,
lastStartedAt: 1625097673875,
nativePath: '/var/ps_assets'
},
{
uri: 'pslib:/',
lastUpdatedAt: 1625344343575,
lastCompletedAt: 1625344343555,
lastStartedAt: 1625344343448,
nativePath: '/ps/library'
}
]
What is that telling me? Is there a permission issue on the host?
You need to replace PHOTOSTRUCTURE_CONTAINER_NAME with the name of your docker container.
Run docker ps to see your running containers and their names.
I did use my correct docker container name:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
05b77a63a017 photostructure/server:alpha "/sbin/tini -- /ps/a…" 49 minutes ago Up 49 minutes (healthy) 1787/tcp photostructure
$ docker exec -it photostructure sh ./photostructure info --sync-paths
./photostructure: line 3: /bin: Permission denied
./photostructure: line 4: CHANGELOG.md: not found
./photostructure: line 5: can't open https://photostructure.com/eula: no such file
./photostructure: line 9: syntax error: unexpected "("
Ah: this is two lines:
Step 1: shell into your container:
docker exec -it photostructure sh
Step 2: once there, run info:
./photostructure info --sync-paths
Ah! That’s why it worked when I did it manually. 
Derp, it’s not very clear, eh? I had added that switch to help me debug, and didn’t make it very user-friendly.
beta.10 will render it like this:
./photostructure info --sync-paths
[
{
nativePath: '/home/mrm/test',
uri: 'psfile://2NMQsMVCK/home/mrm/test',
lastUpdatedAt: 2021070317011018,
lastCompletedAt: 2021070317011018,
lastStartedAt: 2021070317010407
},
{
nativePath: '/home/mrm/Pictures',
uri: 'pslib:/',
lastUpdatedAt: 2021070317023863,
lastCompletedAt: 2021070317023862,
lastStartedAt: 2021070317011018
},
nextPathToSync: {
nativePath: '/home/mrm/Pictures',
uri: 'pslib:/',
lastUpdatedAt: 2021070317023863,
lastCompletedAt: 2021070317023862,
lastStartedAt: 2021070317011018
}
]
The couple changes are:
the dates are “local centiseconds”: 2021070317023863 is 2021/07/03 17:02:38.63
nextPathToSync will either say “all paths have been synced recently” or the path that is pending a sync run.
Good to know, but as long as you know what it means, you’re the debugger.
So, it’s great that you are going to clean up the “info --sync-paths” output, but do you have any inkling as to why Photostructure is not syncing new photos?
When I added that switch I’d assumed I’d just fudged the conditional for what volume to sync next, but that seems like it’s doing the right thing.
I’ll verify that the interval code that kicks this module is set up properly.
just to add, I’ve experienced the same thing with the node version. But i’ve gotten so used to just pressing restart sync
Another voice saying I have this problem. I have updated the sync time from 24hours to 6 hours. No luck. However, I am on Ubuntu 20.04 btfs using docker. Thinking it would work itself out, but at the same time, realized I need to raise a ticket. Was beaten to it. Let me know if you need any logs.
Thanks for the report and welcome to PhotoStructure, @odd7of8 !
As I was waiting for CI to go green tonight, I thought of a different way to schedule sync jobs and coded it into beta.10, which should resolve this issue.
I’m hoping to release beta.10 late tomorrow or Sunday. 
LOL
I’ve been wrestling with batch-cluster for the past couple days to ensure sync-file health checks run properly and that stderr/stdout streams are flushed completely before resolving or rejecting tasks. When examining (tons) of people’s logs they send in, if their sync got “stuck” it seemed to be due to this issue.
@mrm Leave something to do for Beta 11
There is enough in beta 10 to kick the tires on already, time to release!
