V1.0.0-beta.10 and v1.0.0-beta.11 released 🎉

Hooray.

On one of my Macs I’m getting “Cannot set service name twice” on startup of the new app version (manual download from the website, not an update in place from beta.9). I’ve deleted the application and reinstalled. But still getting this. Any tips?

Crap, I’ll try to reproduce this on my mac now. What version of macOS are you running, and is it a intel or m1 box?

Edit: reproduced and fixing it now.

Releasing beta.11 now with this fix.

Note that there’s no substantive difference for server builds between beta.10 and beta.11.

1 Like

OK, verified that beta.11 launches and syncs on macOS, Linux, and Windows.

There are three issues I’m aware of:

  1. There’s an issue with Sentry not initializing properly. This shouldn’t be user-visible, but if there are errors, they don’t get reported

  2. The prior library path isn’t being transferred over. I know what’s going on, and I’m fixing it.

  3. The signal lights on macOS got droopy:

image

On Windows 10 desktop beta 9, I did the check upgrade and it successfully upgraded to beta 11. After the upgrade PhotoStructure did not automatically start; I don’t know if it should.
After starting the program I went to Help/About… and the About window displayed “Error Internal Server Error” I closed the window and opened About again and normal information displayed

Crap. If you restart PhotoStructure, is this reproducible as the first view of the about page?

In first start-up of the program, it automatically started and did some minor syncing but the About window initially displayed with Internal error mentioned above…

I shut down Windows 10 desktop beta 11 and then restarted the program. This time I was asked to login to my account again and select the PhotoStructure library (the default library location was shown and selected and I had to change the library to where my library is located) All photo locations were correctly shown. Once I had logged in and library location selected, it worked correctly with no obvious syncing etc. The About window showed correctly.

Thanks for those details! If you could send me your logfiles, hopefully they’ll have the error from the about page.

Right: I know what’s going on there, and I’ve fixed it in beta.12.

Don’t know if I caused this or not, but figured I would mention it.

Had loaded beta.10… had it rebuilding (slow) my database.

Then 11 came I and I thought “why not”, so I updated to 11.

It went through the “welcome” and “settings” screen instead of just starting. Had all my data and after clicking through it picked up where it had been and seems to have finished just fine.

This is a docker running on unRaid.

So… short version - when should you see the welcome screen?

Had the same (also unRIAD) and it did give me a scare, I am on Plus so needed to get the code but after that all good.

Just another data point… I am on Unraid and went directly from 9 to 11 without the issue you describe.

The welcome screen shows if there isn’t a prior library path set.

Unfortunately, the settings migration script had a bug that didn’t migrate that one setting… I’ve patched it in beta.12: PhotoStructure | 2021 PhotoStructure release notes

:bug: Prior-to-beta.10 library paths were ignored by beta.10 and beta.11. This meant if you upgraded to beta.10 or beta.11 you’d have to re-select your library.

Sorry about that!

I found another bug in beta.10/beta.11: I refactored the settings configuration code in beta.10, which can cause this issue:

Error: code ENOENT: ENOENT: no such file or directory, open '/ps/config/PhotoStructure/settings.toml'

The prior behavior defaulted writing settings directly into /ps/config, but beta.10/11 wants to write to /ps/config/PhotoStructure.

This will be fixed in beta.12: sorry for the inconvenience!

Since latest beta, the new ps gen paths are fine, but source paths have initial slash doubled, like

//[var](http://10.111.10.100:1787/tag/fs/var)/[photos-backup](http://10.111.10.100:1787/tag/fs/var/photos-backup)/[MacPro](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro)/[Pictures](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures)/[macpro.wend](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend)/[Aperture Library.aplibrary](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary)/[Masters](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters)/[2012](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters/2012)/[156_PANA_2](http://10.111.10.100:1787/tag/fs/var/photos-backup/MacPro/Pictures/macpro.wend/Aperture%20Library.aplibrary/Masters/2012/156_PANA_2)/P1560757.JPG

First - thanks for the update!

I am a noob with docker but here is my experience, probably self-inflicted – I edited my run (terminal/cli) bash script from beta 9 to 11, and ran it. it took me thru the welcome and login, verify, then the settings. i was lazy and just clicked ‘manual’ on where to scan but did not fill in all of the various places that I had entered previously… I will check later to see if it actually re-used my previous settings or not.

It did remember my previous file paths, and picked up the new photos I added today. thanks!

Apologies: I’ll get this fixed in beta.12 and try to get that released tonight or tomorrow.

Nope, it was me-inflicted, apologies!

Is there a way to work around this in the meantime?

I’m shipping beta.12 right now: it should be available in a couple minutes on dockerhub.