Is it safe to upgrade from v1.78 to v1.79 for someone who was using Read-only Gallery from start?
Hi, have been using eternal libraries when they were an "experimental" feature in the following setup:
- Account > Manage your account > EXTERNAL PATH > /mnt/archive/photos
where a "/mnt/archive/photos " is local path in a docker container to a mounted 1 folder with all existing photos
So now when we have a dedicated settings section to "Libraries" what is going to happen to this "Account > Manage your account > EXTERNAL PATH" setting?
What are the steps for someone who wants to keep all the already indexed and processed photos and videos in this situation?
46 Replies
@etnoy Do you have any thoughts on this?
so I've warned everyone that if they are on a PR branch they might need to delete the db and start again
@andreessenhorowitz how old is your docker image?
take a backup of the postgres database and switch to the release immich
it should work, but if not you have a backup
@Alex @etnoy Hi, thank you so much for your reply. The last time I updated was 2023-09-15 19:49:03 so currently I'm on v1.78.1
I guess worst case scenario I will need to reprocess and reindex all files again? even though I have 76K files I'm ok with that since I remember it did not take too long.
yes, that's the worst case. You should be good to go but a backup is always a good idea
by the way on this topic as well, have you added support for Sony raw photos for this "external libraries feature"? I remember when I tried the last time this import using CLI it did not work
I think it should work now
now we do not need to run CLI command and can just click "Scan All Libraries" button in settings to import any new files added right?
Yes
This is amazing!!! Thank you so much
@etnoy can you suggest if I should remove the path in Account > Manage your account > EXTERNAL PATH settings before the update and then after updating to the latest version add this path as a new "External Library" in new settings? I'm just afraid to get any duplicate data both in postgres or somewhere else for the same library or existing photos and videos.
why would you remove the path? Just upgrade to the release version and everything should stay the same
@etnoy if a user was never on a PR branch and using the external photos support (import instead of upload), how are these handled when updating to 1.79?
those are not touched at all so they should be fine. Although I heard from somewhere that importing photos this way is currently broken. Haven't had time to check yet
What about wanting to migrate these photos to be an external library? I'll reprocess everything again if I have to buy wasn't sure if there was a migration path
there is currently no migration path except to put them in a folder that can be imported via external library
Got it
The migration path is SQL update read only files into their own external library š
I was just checking this out - so this is safe to do?
Just update the libraryId in the DB?
and set isExternal to true?
I'm not sure about all the booleans, but that sounds correct. Library is essentially just a group of assets via libraryId and the I believe booleans disable actions in the UI.
@etnoy does this sound right? Might give it a whirl.
yep, that works!
There was a closed PR that was going to migrate read only assets to a external library. You could double check that too
but what will happen on next rescan?
Just need to make sure import paths cover the new assets
yep, but I wanted to include the caveat
but I haven't tested this myself
Imo for large libraries it is worth doing vs reprocessing everything.
Just export the database first ofc
@etnoy are exclusion patterns comman-delimited?
in sql?
they are an array of strings in node
In the UI
oh, just one per row
you can add several š
When adding them
oo nice
Docs have good examples btw
I must have missed the exclusion part š
you excluded it
š
Mind giving a second set of eyes before I run this?
Looks good
Are you the only user?
No, good call.
Yup
Looks good
backup first always a good idea
Yup I did that
Looks like it worked!
Because I want to completely transition to using new "Libraries" instead of "Read-only Gallery [Experimental]"
we still use the external path in external libraries
We need better documentation around "external path". For both libraries and the previous "read only gallery" a user can specify any input path without even having access to the server. That has security implications, especially in an environment where you have multiple users. External path is really a path whitelist, which allows/disallows users from using certain paths in either of the two previously mentioned features.
If you, the admin, add
/admin/family/photos in your library, and you don't want another user barely-trustworthy-bill from being able to create an external library that points to /admin/family/photos you need a rule that prohibits it.but only the admin can set external path, right?
I think I added some documentation in the library docs that also talks the importance of securing the external path
Yes, there is a Security Considerations section in the documentation. It would be great if it was highlighted with "CAUTION" styling as well since it is very important.
Maybe even an angry warning in the UI when you set a path
:::danger I think?