Testing on Ubuntu 22.04 LTS - Desktop Version.
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.
I’ve just added that to the buglist, and I’ll look into it asap.
Ah! Holler if this doesn’t fix the issue: https://forum.photostructure.com/t/version-2-1-0-alpha-is-ready-for-testing/1456#omg-i-upgraded-and-my-screen-is-blank-11
I did place this in the settings.toml and it worked.
RTFM, I guess. My sincere apologies.
I did the exact same thing.
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 theContent-Security-Policy-Report-Onlyheader rather than the standardContent-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--exposeorexposeNetworkWithoutAuth=true. If explicitly set tofalse, it changes the default ofcspReportOnlyto true andupgradeInsecureRequeststo false. If you’re accessing your PhotoStructure library via the web interface, you want this set totrue.
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.
@mrm - I wiped the library out and recreated the container. The sqllite error re-occured. I will DM a link to the logs off my google drive.
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 did a full rebuild with the new version and it seemed significantly faster… but that was just perceived.
Hello @mrm
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:
transcodeBitrateQVGAtranscodeBitrateUHDdoNotTranscodeMimeTypesdoNotTranscodeVideoCodecsdoNotTranscodeAudioCodecs
I added it! See New in v2.1: file globbing
Done per PM.
but they will still be visible in the library with a thumbnail or not at all?
Oh, I see, I need to check it out. Thank you!
I was running for a while (Thanks @mrm for help with the DB restore!), and PS crashed. Now trying to start it with --versbose flag seeing:
2022-05-09T11:36:38.148Z main-2626615 error Error onError() { event: 'fatal', message: "Can't restart sync, failure rate is too high.¹" }
2022-05-09T11:36:38.149Z main-2626615 error exit() exit() { reason: "Can't restart sync, failure rate is too high.¹",
status: 12,
ending: false }
Any way to quickly fix t?
Thanks!
If you want to send DM/email me the prior log lines, that’d be great.
Glob support is in the release I hope to get out tomorrow, BTW, not the current alpha. 1 release.
Emailed.
