Folder structure of external libraries does not correspond to the actual folder structure

[lantura]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

Folder structure of external libraries (immich server) does not correspond to the actual folder structure
The folder structure of an external folder is not displayed correctly in immich server.
The folders are sorted by year and within these folders by month and a short description of the content.
However, if a year folder contains only a single subfolder, the folder structure is not transferred to immich. Instead, these folders are displayed at the year folder level, even though the structure on the hard drive is different.
It appears that if there is only one subfolder in such a year folder, the parent structure of the year folder is not transferred (see, for example, 1984). If another folder is subsequently saved in the year folder, it is not displayed despite repeated rescans.
In the mobile version of immich, however, the folder structure is displayed correctly, as it is in Windows Explorer.

1. Is this error known?
2. Why are new folders not read in despite rescan?
3. Why does the display of the folder structure differ between the mobile app and the server version?

View Windows Explorer:

View external folder in immich:

immich unraid template:

The OS that Immich Server is running on

Unraid v7.2.2

Version of Immich Server

v2.3.1

Version of Immich Mobile App

n/a

Platform with the issue

• Server
• Web
• Mobile

Device make and model

No response

Your docker-compose.yml content

see screenshot "immich unraid template"

Your .env content

see screenshot "immich unraid template"

Reproduction steps

1. Scan external library
2. Rescan external library

...

Relevant log output

Additional information

No response

[bo0tzz]

Is the new asset showing up elsewhere in the web client, and does its detail panel show the expected path?

[lantura]

Yes, the new asset is displayed correctly in the year folder.
I have now noticed that the folder structure is displayed correctly as soon as there are at least two subfolders in a year folder. If there is only one subfolder, the folder structure is not displayed correctly. If another folder is subsequently created in a year folder with only one subfolder, the correct folder structure is then applied in the web app.

[lantura]

If a second subfolder added to a yearly folder is removed, leaving only one subfolder in a yearly folder, the folder structure is again not displayed correctly in the web app. The mobile app shows the folder structure.
The mobile app continues to display the correct folder structure.

[bo0tzz]

Can you please describe exactly what you're seeing in each case, and provide detailed reproduction steps?

[lantura]

Steps:

1. Create and scan an external library -> Note that the folder structure in the web app is not displayed correctly for annual folders that only contain one subfolder. Such folders are displayed at the top level.
2. Create an additional second subfolder in such annual folders -> Result: The folder structure is displayed as it exists on the hard drive. Subfolders are displayed correctly under the year folder.
3. The subfolder that was just created is deleted again -> Result: the folder structure no longer corresponds to the structure on the hard drive (display as in step 1).

General: If year folders contain only one subfolder, these subfolders are displayed at the top level with the year folders.

[bo0tzz]

I still don't understand the issue. Is it that the full path is displayed if a folder has only one subfolder? If so, that's working as expected - making you click through a bunch of otherwise empty folders would just be unnecessary.

[lantura]

Yes, that's how it is in the web app. But this is not consistent with the mobile app, as the correct folder structure is displayed there, even if a year folder only has one subfolder.

[alextran1502]

To better understand the issue, can you pick one example that shows your expected behavior and the app's erroneous behavior? So that we can compare side-by-side if it is an issue?

[skatsubo]

There is a known issue in the Folder View sorting. Could it be your issue?

• Sorting bug on external library #22696

If I correctly interpreted "folder structure" as "sort order" and the screenshots:

The bug was fixed recently, and the fix will be released in the next Immich version.

• fix(web): folder view sort oder #24337

[lantura]

This is not about sorting folders, but about displaying the hierarchical structure of folders. Is it works-as-designed that folders with only one subfolder are not displayed hierarchically? Instead, the subfolder is displayed at the top level?
If so, why is this not consistent with the mobile app?
The (hierarchical) structure of folders should be displayed in the same way as the physical structure on the storage medium.
And this should be implemented consistently across all apps (web, mobile, etc.).

[skatsubo]

"with only one subfolder" as "collapsed" was introduced for the web UI in this PR:

• refactor(web): tree data structure for folder and tag views #18980

In the folder view, collapses path sections that are shared across all subtrees to avoid unnecessary clicks

[meesfrensel]

There are two things at play here. First, confusion due to the folder view sorting.

This is not about sorting folders, but about displaying the hierarchical structure of folders. Is it works-as-designed that folders with only one subfolder are not displayed hierarchically?

Yes

Instead, the subfolder is displayed at the top level?

Yes and no. The subfolder is displayed together with the base folder. For example 1984/july. This reduces the number of clicks to get into a place where there are more than 1 item in the folder. What confuses you is that the 1984 folder is not sorted between 1983 and 1989 but shown later on. Updating your Immich server will make this more clear!

Second:

If so, why is this not consistent with the mobile app?

This can be considered an actual issue with Immich.