Bug, I think: Sync => Pause processing/Resume & Restart Sync is not doing anything for me. This is an issue when you have a big library and the process got interrupted. Even after a restart (app and system) it doesn’t continue with the import/scan process. A “forced” restart sync from the menu doesn’t help either.
It seems “exposeNetworkwithoutAuth” is also not working…it generates an URL, but the page stays white. Tested on iPad, Android, Win 10 with Chrome, Safari, Firefox and Edge.
No worries at all: I appreciate your help in banging on the alpha build, and I suspect this will trip up more people.
Is there a safe way I can default to making things “work by default”, I wonder?
For reference, v2.1 now has the following CSP/CORS/ “web security” settings:
upgradeInsecureRequests, if true, adds the upgrade-insecure-requests CSP directive. If false, the directive is omitted. CSP linters suggest that it be included.
cspReportOnly, if true, uses the Content-Security-Policy-Report-Only header rather than the standard Content-Security-Policy. CSP violations are only reported. This should only be set to true temporarily for debugging CSP errors.
enableWebSecurity: this defaults to true if you use --expose or exposeNetworkWithoutAuth=true. If explicitly set to false, it changes the default of cspReportOnly to true and upgradeInsecureRequests to false. If you’re accessing your PhotoStructure library via the web interface, you want this set to true.
So, with that out of the way–perhaps I default upgradeInsecureRequests to false?
After explaining this, I think enableWebSecurity is too confusing and complicated: I’m going to delete it.
Related: did people know that there’s a trustProxy setting? It currently defaults to false because I’m chicken, but I think defaulting it to loopback might be almost as safe of a default. More defaults about trustProxy are here.
Upgrade insecure requests assumes that you are capable of serving over https. How many of your users do you think are using https? I would leave it out until such a time as Photostructure supports https out of the box.
@mrm - by the way, this was with a brand new library (I always wipe everything out between version upgrades). When I restarted the container it continued where it left off and it has since complete successfully. I will retry from scratch again this weekend, just to see if I reproduce.
I take that back. After some testing it works for me, but I changed now from CIFS to NFS, which might or might not have something to do with it.
Is it just me or is the import process much slower than in other versions? It’s running now for 2 hours or so and it feels significantly slower.
Update: I might understand now why it feels slow. It seems that (obviously) videos take much more time to import. Once that is done, the progress on the photos is a lot faster…so it’s a perception thing…
I have now imported my library with 36k images and ~1k videos. The sync-report is quite helpful, thank you!
Some observations:
After ~26 hours and 19k processed pictures the process just stopped and I had to force a re-sync, after another 12 hours the remaining pictures got processed
I have quite a few pictures that got rejected with “dimensions too small” or “file too small”
Seems like “wmv” is not supported => “not supported mime type, dimensions too small”
Seems lime “bmp” is not supported => “not photo or video extension”
I have quite a few pictures that failed with “Cannot build previews: none of the files are valid: VipsJpeg: Invalid SOS parameters for sequential JPEG²ⶔ (happy to provide an example file per PM message)
Building on my observations a few questions/comments:
Many videos got rejected because they are too big or too small. In fact I would actually prefer to not process videos at all, but “link” to the original source instead and displaying a thumbnail only. This would save a lot of processing time and keep the overall footprint small. I understand that not all users would like to have it like that, but as an option I would appreciate that
It would be helpful too understand what parameters to tweak if you have a lot of CPU power, if you have a lot of RAM, or even both
Adding folders to exclude (also ex-post) as per my PM would be awesome
Overall it runs so far very stable and does what it should.
Many videos got rejected because they are too big or too small. In fact I would actually prefer to not process videos at all, but “link” to the original source instead and displaying a thumbnail only.
You can tell photostructure not to transcode videos. Either set transcodeVideos=false in the settings file, or set the PS_TRANSCODE_VIDEOS environment variable to false. (depending on how you’re running photostructure)
Please do send me any photos or videos whose dimensions are not being extracted correctly!
As @avdp stated, there’s a PS_TRANSCODE_VIDEOS which is the big switch to disable all transcoding, but you can configure which video types get transcoded, and at what bitrate, via the following settings:
