Feature request: Set the album description

[mspoorendonk]

I have album descriptions in text files inside the folder structure that defines my albums on disk. Would be great if your script would read those. Preferably using a standard format. (I will then make sure to first convert my proprietary files (such as picasa.ini files) to this standard.

[Salvoxia]

Thank you for your suggestion!
I think I'll have to disappoint you, though. This feature would require the script to have direct access to the files that are mounted as external library into the Immich container. The design philisophy at the moment is to only interact with Immich's API, which can happen from anywhere the Immich API can be reached from. The script does not have to run on the same server and there are no permissions to take care of.

Unless such a feature is requested by many people, I don't think it will be added.
Sorry.

[Kernald]

Just replying because of this:

Unless such a feature is requested by many people, I don't think it will be added.

I was about to request a similar feature, where a text file at the root of an album would be able to override e.g. the album title if present, or listing the name of a specific asset of the album to use as a thumbnail. So, yeah - at least plus one person requesting this. I feel like this could be added as an optional argument for the local path to the data, and a pretty simple match (e.g. if Immich sees the external library as /mnt/photos but my laptop on which I'm calling this has it mounted as /Volumes/photos, calling this script with /mnt/photos --local /Volumes/photos, matching local and remote assets is as simple as removing the relevant prefix).

I definitely appreciate that it's a bit of a departure from the way it works at the moment though.

[Salvoxia]

By setting --album-levels as a range it's possible to have assets from multiple folders added to the same album. How would you expect the script to behave in such cases?
Thinking hypothetically at the moment.

[Kernald]

That's a fair question - I'm not using ranges so I hadn't thought of it. I feel like it's an edge case that, as long as it's well defined (and documented), doesn't matter too much - maybe consider only text files at the root of what would eventually create the album? E.g. if foo, foo/bar, foo/bar/baz and foo/qux were ending in a single foo album, only a foo/.albumprops (or whatever name) file would be considered. Raising a warning if a foo/bar/.albumprops was found but not used would also make it obvious when something like that is going on.

[Salvoxia]

Concept for implementation

Prerequisites:

• Docker: All root paths must be mounted under the same path to the immich-folder-album-creator container as they are mounted to the Immich container
• Bare Python Script: The script must have access to all root paths under the same path as they are mounted into the Immich container; either mount the folders into Immich under the same path as they are on the Immich host, or create symlinks for the script to access

.albumprops File Format

A file named .albumprops may be placed into any folder of an external library.
The file itself is a YAML formatted text file with the following properties:

# Album Name overriding the album name generated from folder names
override_name: "Your images are in another album"
description: "This is a very informative text describing the album"
share_with:
  # either provide user name
  - user: "user1"
    role: "editor"
  # or provide user mail address
  - user: "user2@example.org"
    role: "viewer"
# Set album thumbnail, valid values: first, last, random or fully qualified path of an asset that is (or will be) assigned to the album
thumbnail_setting: "first"
# Sort order in album, valid values: asc, desc
sort_oder: "desc"
# Flag indicating whether to archive images added to this album, valid values: true, false
archive: true
# Flag indicating whether assets in this albums can be commented on and liked
comments_and_likes_enabled: false

All properties are optional.

Enabling .albumprops discovery

A new option --read-album-properties is introduced. If passed, the script will search for .albumprops files and use the values found there to created the albums.

Property Precedence

In case the script is provided with --share-with, --share-role, --archive, --set-album-thumbnail options, properties in .albumprops always take precedence. The options passed to the script only have effect if no .albumprops file is found for an album or the specific property is missing.

High Level Algorithm

High Level Algorithm for CREATE mode

Search all root_paths recursively for .albumprops files
Parse each found .albumprops file and create internal model
Sanity check: If any two .albumprops files specify the same override_name throw an error and exit
Use create_album_name() function for path of each .albumprops files; if more than one .albumprops paths generate the same album name, throw an error and exit
Query assets, create album names as usual
Enrich created albums with properties from .albumprops
Apply missing properties passed by --share-with, --share-role, --archive and --set-album-thumbnail options
Create albums, add assets and patch albums with specified properties

[Kernald]

This sounds great! I'm just wondering, in terms of the album cover, if we could instead (or in addition to the currently planned options) refer to a specific asset by filename? I understand that the current options are what currently exist in this script, hence simpler to implement, so maybe an idea for the future, but designing the configuration file with that in mind might be nice.

[Salvoxia]

Thanks for your feedback! Doesn't sound too bad in terms of effort. However, due to the possibility of multiple files from different folders present in the same album, a simple file name might not be unique. Furthermore, taking the possibility of multiple root paths into account well, it would have to be a fully qualified path to actually be unique in any case.
With some kind of fallback if the file does not exist.
What do you think?

Edit: On second thought, a fallback might not even be necessary. If the file does not exist, no new thumbnail/cover would be set, so that's a non-issue.

[Kernald]

Fully qualified path sounds good yeah!

[Salvoxia]

A working prototype is available in branch feat/advancedAlbumProps.
It needs to be polished (linting fails) and tested more.
Option --read-album-properties is still missing.
Docker not yet updated.

Otherwise, should be functioning.

Tests and feedback are much appreciated!