Make Storage Template the default feature
I wonder why the storage template is not enabled by default. I think most people would be okay if we use a format like ‘year/month/date’ as the default. And they can change that if needed.
Struggling to understand why the ‘upload’ folder is the default one. I see a question now and then on how does the folder structure looks so weird (referring to the upload folder).
24 Replies
:wave: Hey @radh,
Thanks for reaching out to us. Please follow the recommended actions below; this will help us be more effective in our support effort and leave more time for building Immich :immich:.
References
- Container Logs:
docker compose logs docs
- Container Status: docker compose ps docs
- Reverse Proxy: https://immich.app/docs/administration/reverse-proxy
Checklist
1. :blue_square: I have verified I'm on the latest release(note that mobile app releases may take some time).
2. :blue_square: I have read applicable release notes.
3. :blue_square: I have reviewed the FAQs for known issues.
4. :blue_square: I have reviewed Github for known issues.
5. :blue_square: I have tried accessing Immich via local ip (without a custom reverse proxy).
6. :blue_square: I have uploaded the relevant logs, docker compose, and .env files, making sure to use code formatting.
7. :blue_square: I have tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable
(an item can be marked as "complete" by reacting with the appropriate number)
If this ticket can be closed you can use the /close command, and re-open it later if needed.Files can't be put into the correct location on upload because the EXIF data isn't known. So they have to go somehwere to start. And any time we move it after that there is a tiny chance of a failure
It is very stable lately and we may do this at some point but that is the logic
Right. I understand that even when I use the ‘storage template’, the upload folder is used as a buffer. But just that it seems confusing for people that get started with immich. Since they need to manually toggle the feature to have a sensible folder structure.
I agree on the stability part of it. But using Storage Template has also been stable correct?
I have been using the storage template for more than a year, and everything seems good.
It's stable as your backing filesystem
for a lot of people, that is "not very". lol
Oh. I did not know about that.
Filesystems are generally fine, and the storage template system is built to be hardened against failures like that now
However, you'd be surprised how many people actually don't care what their files look like on disk
The beauty of something like immich is that you can see everything and search it all, etc
The problem with the storage template system is it requires a move operation, and that can have pretty intensive IO impacts depending on your mount setup or the underlying filesystem
I dont look at it either 😂.
lol, so why do you care what they look like? 😛
I think if people want to move out of immich. They would most certainly run that job once.
Also, on the IO - this applies only to the first import right. Any future uploads are going to be relatively small to make a huge impact.
It's just unnecessary, if people want to move out, they can run the storage template then
The thought was to simplify the feature set if possible. No real use case for me
We originally had it enabled by default, but it's just not necessary for a majority of users
So it seems needless
With certain setups you can end up with the move being an entire copy of the file, maxing your IO if you're running on hard drives
It significantly impacts initial import times if that happens
My concern is that having it disabled makes Immich (and specifically the DB) more of a single point of failure. DB gone = you're left with a bunch of random uuids for files
Never thought of that. But that is definitely a concern!
Simply, have backups, we're not going to re-enable it by default lol
We had a good reason for disabling it by default, I don't intend on us flip-flopping between those
There was someone whose DB backup didn't work and I had to tell them to write a script with exiftool to salvage the files. I get why it was disabled but this is also a bad place to be that a user isn't necessarily aware they're signing up for
We are planning to add in an automatic backup system for the database by default anyway, so that's not really a concern for me
If the concern is that it isn't clear, we can add more detail to the onboarding page
Explaining what the default format looks like
I would argue that for the end user, the storage template adds a huge peace of mind. It is like the immich team says ‘hey, even if immich gets messed up -> database is lost, or the database backup is lost/corrupted, your memories are still safe and in a format that makes sense to the human eye’. If this was the case, the user knows that if something like that happens, they can just give up on that app (here immich) and move on. Without the struggle of getting into a process to get their data into a sensible format - even though that process could be explained in detail in the docs.
I'm up for clarifying this in onboarding, and then people can make that choice for themselves
I think that will make it clear enough
This would definitely help. I don't think the onboarding section makes it really clear what the storage template feature does or what disabling it really means. It explains more if you enable it, but a lot of users end up skipping it because the description sounds vague and ominous. When I mention the storage template to those users, they were looking for just that but never actually knew about that feature
Yea, just sounds like a UX problem to me
Storage template was the reason onboarding was originally built
So can probably use some work
Hey. Something just popped in my mind. I have no software background, so take this with a grain of salt.
What if the clients that are uploading an asset, extract the exif from that asset - send that first to the server. Then immich knows where to put that asset according to the storage template. Now once everything is smooth and ready on the server side, the client can then push the actual asset. This asset can go directly to say ‘year/month/date’ - instead of upload and then ‘year/month/date’. I suppose something like this might fix the IO issues?
It's a valid option and some projects do go for a more client-side strategy. But it means having separate implementations for metadata extraction on clients, which need to be maintained and can have different behavior from each other. It also means that uploads are now branched into two cases that need to be tested separately.
And since we still have an API that other projects use, we can't expect each third-party client to handle EXIF metadata as well, meaning the current implementation would still exist anyway.
Yeap. You make a lot of sense.