Error "[UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters"

[zjr]

Expected Behavior

PhotoStructure turns on and begins syncing. The About page should work.

Current Behavior

Sync does not happen when I turn on PhotoStructure. It actually appears that nothing happens. Furthermore, the “About” page opens with an “Internal Server Error” and none of the information I’m expecting.

I think I’ve isolated the correct warning in the sync log file, but I can’t find any place in my settings where I’ve given a URI with “two slashes”

{"ts":1666109594231,"l":"warn","ctx":"Error","msg":"onError(): Error: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters (\"//\")\nError: [UriError]: If a URI does not contain an authority component, then the path cannot begin with two slash characters (\"//\")\n    at /tmp/.mount_PhotosScHrDD/resources/app.asar/sync.js:9:565077\n    at new y (/tmp/.mount_PhotosScHrDD/resources/app.asar/sync.js:9:565212)\n    at new w (/tmp/.mount_PhotosScHrDD/resources/app.asar/sync.js:9:567175)\n    at Function.from (/tmp/.mount_PhotosScHrDD/resources/app.asar/sync.js:9:566392)\n    at Object.t.nativePath2pslib (/tmp/.mount_PhotosScHrDD/resources/app.asar/sync.js:9:573585)","meta":{"event":"nonFatal","message":"unhandledRejection"}}

Steps to Reproduce

1. Have a working PhotoStructure library on a Dropbox Account on a different computer.
2. Get a new computer, install PopOS 22.04,
3. sync Dropbox to a local folder. Get the current PhotoStructure for Desktops AppImage
4. Open photostructure; enter usual settings.

I’m wondering if this has something to do with the .photostructure/uid.json or .photostructure/.library-uid.json files in my library which was created by another computer. But I’m afraid to delete the files because I don’t fully understand what they do.

I tried both true and false for PS_FORCE_LOCAL_DB_REPLICA

Environment

Operating system and version: PopOS 22.04

PhotoStructure edition: Photostructure for Desktop. 1.1.0 (I think I’m reading that correctly from the logs; but can’t tell for sure because the About page doesn’t work)

[mrm]

Howdy @zjr , welcome to PhotoStructure! Apologies for the glitches.

It looks like PhotoStructure’s URI generation is what we’re fighting here.

Here’s the explanation for why PhotoStructure uses these URIs: PhotoStructure | What's a “drive,” or “volume?”

I suspect the issue is with the Dropbox mountpoint not being parsed correctly. I’ve never run Pop!_OS before, but either way, getting some logs to look at should shake out some clues as to what’s going awry.

1. Make sure you have backups of your photos and videos.
2. I suggest using PhotoStructure for Node instead of the desktop version–it’s proven to be more stable for more people. The setup should be quite quick if you’re comfortable with the terminal.
3. Switch to the alpha branch: git checkout alpha (there are several URI improvements in the v2.1 branch).
4. Run ./start.sh info --volumes --debug > out.txt
5. DM or email me the out.txt file

If chat is easier, hop into the Discord–I’m online.

[zjr]

Thanks! I knew I had read about uuids somewhere in the docs, but I couldn’t find it earlier today.

If I’m understanding the link you provided correctly, the .uuid file that gets generated by the tool is different than the one in ‘[library dir]/.photostructure/.uuid’.

It seems like Dropbox is syncing over a .uuid file that is different now that I’m on a different physical hard drive. Which means I probably need to follow this solution:

If you add or change a .uuid #

PhotoStructure assumes that volume UUIDs are stable.

If you change the contents of a .uuid or add a new .uuid to a remote volume you must rebuild your library, via the system navigation menu.

Read more about rebuilds here.

You can select rebuild while an import is running: it will fix currently-imported assets, and then continue with importing.

Does that sound right? I’ll try it later today when I get a chance.

[mrm]

@zjr

I’m wondering if this has something to do with the .photostructure/uid.json or .photostructure/.library-uid.json

Ah! There’s a difference between volume UUIDs and that “uid.json” file you found.

The .uuid file, most of the time, should only be found in the root directory of a given volume. PhotoStructure tries to make the contents of the .uuid file match the hardware UUID of the device, just to make it stable, but if for whatever reason it can’t extract the hardware UUID, it will generate a random UUID. If a .uuid file is present, PhotoStructure always uses the value in there instead of the hardware UUID.

The uid.json file is used for licensing–if a bunch of other system metadata changes (say, you move the library on an external drive to another computer), it may allow your PLUS license to stay active.

If for any reason you find your PLUS license isn’t active, though, just visit the about page and click the first link–another license will be added to your library, so your library can use your PLUS license on both computers.

[zjr]

Rebuild seems to have fixed the issue! I’m also moving off of bidirectional backups, as the doc you linked to suggests. Thank you for your prompt attention! Cheers!

[zjr]

Hi Matthew,

I wanted to follow up on something I noticed. Not sure if this is expected behavior or not. I had made some changes to the Library Settings at .photostructure/settings.toml (specifically, I set assetSubdirectoryDatestampFormat = 'y/y-MM'). When I rebuilt the library, it seems like it wiped the TOML file and restored to defaults. (to 'y/y-MM-dd').

I suppose that maybe makes sense that a ‘rebuild’ would totally start from scratch and probably avoids some issues. However, my first expectation would have been that it would use the settings I had adjusted.

Either way, I fixed the issue by copying all the photos to a separate directory and re-imported them after I had restored my version of the TOML file.

[mrm]

@zjr

When I rebuilt the library, it seems like it wiped the TOML file and restored to defaults. (to 'y/y-MM-dd').

Rebuilding your library should only re-analyze the asset file metadata and asset aggregations in your library database. Details are here:

https://photostructure.com/faq/sync-vs-rebuild/#-library-rebuilds

PhotoStructure rewrites both the system and library settings.toml files only when it determines that they are from an older version of PhotoStructure, and it should try to migrate your prior settings to the new setting names or newer formats… Otherwise, it should leave those files alone.

In version 2.1 I changed the settings for automatic organization: assetSubdirectoryDatestampFormat was replaced with assetPathnameFormat. There’s code that should translate your assetSubdirectoryDatestampFormat value into assetPathnameFormat format, and then re-save the settings.toml. If it didn’t do that, please tell me and I can look into it.

If you open your library’s settings.toml, you should see these comments:

assetSubdirectoryDatestampFormat

Deprecated as of version 2.1: please use assetPathnameFormat instead.
If this setting is provided, and assetPathnameFormat is not provided, we will give assetPathnameFormat the value of this setting + “/BASE”.

assetPathnameFormat

If you opt into “automatic organization” (see the setting “copyAssetsToLibrary”), they will be copied into <originals directory>/<result of assetPathnameFormat>.

• See the originalsDir system setting for what your is (it defaults to your library root directory).
• Please encode this path with forward-slashes, even if you’re on Windows.
• If any patterns resolve to including forward-slashes, know that will be interpreted as subdirectories.
• If you want to add a static path, escape the pathname with single quotes (like “‘photos’/y/MM/dd”).
• The result of this will always be interpreted as a relative path from your PhotoStructure originals directory.
• Use token “BASE” as a shorthand for the original basename (“photo.jpg” for “/path/to/photo.jpg”).
• Use token “NAME” as a shorthand for the original filename, without the file extension (“photo” for “/path/to/photo.jpg”).
• Use token “PARENT” as a shorthand for the original file’s parent directory name (“to” for “/path/to/photo.jpg”).
• Use token “GRANDPARENT” as a shorthand for the original file’s grandparent directory name (“path” for “/path/to/photo.jpg”).
• Use token “EXT” for the filename’s extension without the “.” prefix (like “jpg” for “/path/to/photo.jpg”).
• Use token “ISO” as a shorthand for “yyyy-MM-dd’T’HH:mm:ss.SSSZZ”.
• You can escape other static text by wrapping with single quotes.
• For other tokens, see https://moment.github.io/luxon/#/formatting?id=table-of-tokens.
• See How to change the naming structure? - #2 by mrm for more details.