Folders: Child paths may overwrite parent folder albums #2448

Author

Owner

@graciousgrey commented on GitHub (Dec 5, 2025):

. I haven't even see any one of these sections on the toolbar.

You can find these sections on the main navigation after you have clicked on the arrow down next to Search.

@graciousgrey commented on GitHub (Dec 5, 2025): > . I haven't even see any one of these sections on the toolbar. You can find these sections on the main navigation after you have clicked on the arrow down next to Search.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Dec 5, 2025):

. I haven't even see any one of these sections on the toolbar.

You can find these sections on the main navigation after you have clicked on the arrow down next to Search.

I see them now. Sorry I didn't read the doc carefully. Thanks for your guide.
While there are 7000+ photos in the review section, after I unclicked Quality Filter, the number of folders only increased by one with a lot of more parent folders being invisible.

@s0ren99 commented on GitHub (Dec 5, 2025): > > . I haven't even see any one of these sections on the toolbar. > > You can find these sections on the main navigation after you have clicked on the arrow down next to Search. I see them now. Sorry I didn't read the doc carefully. Thanks for your guide. While there are 7000+ photos in the review section, after I unclicked Quality Filter, the number of folders only increased by one with a lot of more parent folders being invisible.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Dec 6, 2025):

. I haven't even see any one of these sections on the toolbar.

You can find these sections on the main navigation after you have clicked on the arrow down next to Search.

It seems the root cause is PhotoPrism’s folder name normalization / beautification step.

My original folder structure contains many emoji-named subfolders, e.g.:

ins/dloralyfo/
  🧝‍♀️/
  🤯/
  🪞/
  🇯🇵/
  🍑/
  🍹/
  🎃/
  🐠/
  🔗/
  <3/
  F/
  Highlights/
  More here/

PhotoPrism changes how these folders are displayed in Folders view by capitalizing, removing underscores ( _ ), and otherwise “beautifying” the folder names.
For example:

original folder: ins/b._.rume
shown in UI as: B. .Rume

The problem:
One of the emoji subfolders (🪞) gets normalized into the same name as its parent (Dloralyfo) in the UI.
Because of this naming collision, the actual parent folder ins/dloralyfo becomes invisible in the Folders view, and all the other emoji-named subfolders under it also disappear from the UI.

In short:

Parent folder = Dloralyfo
Emoji subfolder 🪞 is normalized → also becomes Dloralyfo
Folder view hides/conflicts with the real parent, making the entire level un-navigable.

This explains why PhotoPrism was showing only some subfolders and not the parent or the rest.

It seems that folder name normalization needs to either:

avoid collisions with parent names, or
allow disabling/overriding the normalization for folders.

@s0ren99 commented on GitHub (Dec 6, 2025): > > . I haven't even see any one of these sections on the toolbar. > > You can find these sections on the main navigation after you have clicked on the arrow down next to Search. It seems the root cause is PhotoPrism’s folder name normalization / beautification step. My original folder structure contains many emoji-named subfolders, e.g.: ``` ins/dloralyfo/ 🧝‍♀️/ 🤯/ 🪞/ 🇯🇵/ 🍑/ 🍹/ 🎃/ 🐠/ 🔗/ <3/ F/ Highlights/ More here/ ``` PhotoPrism changes how these folders are displayed in Folders view by capitalizing, removing underscores ( _ ), and otherwise “beautifying” the folder names. For example: - original folder: `ins/b._.rume` - shown in UI as: `B. .Rume` The problem: **One of the emoji subfolders (🪞) gets normalized into the same name as its parent (Dloralyfo) in the UI.** Because of this naming collision, the actual parent folder `ins/dloralyfo` becomes invisible in the Folders view, and _all the other emoji-named subfolders under it_ also disappear from the UI. In short: - Parent folder = `Dloralyfo` - Emoji subfolder 🪞 is normalized → also becomes `Dloralyfo` - Folder view hides/conflicts with the real parent, making the entire level un-navigable. This explains why PhotoPrism was showing only some subfolders and not the parent or the rest. It seems that folder name normalization needs to either: 1. avoid collisions with parent names, or 2. allow disabling/overriding the normalization for folders.

deekerman commented

Author

Owner

@lastzero commented on GitHub (Dec 6, 2025):

PhotoPrism has full Unicode / UTF-8 support in its database, API, and user interface – emojis and non-ASCII characters in file and folder names should be handled correctly as long as the underlying filesystem uses a compatible encoding:

The symptoms you’re seeing are most likely caused by the filesystem or mount using a legacy / non-UTF-8 encoding, or by incorrect database charset / collation settings, as described in our MariaDB troubleshooting guide under “Unicode Support”:
https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support

PhotoPrism can only see whatever encoding the host file system and database expose inside the container.

Next step: @s0ren99, please open a terminal session in the PhotoPrism container and inspect the filesystem and locale settings (e.g. locale, mount, and ls -b in the affected directories), and verify the MariaDB charset and collation configuration. That will tell us how the filenames are actually encoded and help pinpoint where the mismatch occurs.

@lastzero commented on GitHub (Dec 6, 2025): PhotoPrism has full Unicode / UTF-8 support in its database, API, and user interface – emojis and non-ASCII characters in file and folder names should be handled correctly as long as the underlying filesystem uses a compatible encoding: <img width="520" height="578" alt="Image" src="https://github.com/user-attachments/assets/be941a9c-e032-4296-9d92-92ad15dc919c" /> The symptoms you’re seeing are most likely caused by the filesystem or mount using a legacy / non-UTF-8 encoding, or by incorrect database charset / collation settings, as described in our MariaDB troubleshooting guide under “Unicode Support”: [https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support](https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support) PhotoPrism can only see whatever encoding the host file system and database expose inside the container. **Next step:** @s0ren99, please open a terminal session in the PhotoPrism container and inspect the filesystem and locale settings (e.g. `locale`, `mount`, and `ls -b` in the affected directories), and verify the MariaDB charset and collation configuration. That will tell us how the filenames are actually encoded and help pinpoint where the mismatch occurs.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Dec 6, 2025):

PhotoPrism has full Unicode / UTF-8 support in its database, API, and user interface – emojis and non-ASCII characters in file and folder names should be handled correctly as long as the underlying filesystem uses a compatible encoding:
The symptoms you’re seeing are most likely caused by the filesystem or mount using a legacy / non-UTF-8 encoding, or by incorrect database charset / collation settings, as described in our MariaDB troubleshooting guide under “Unicode Support”: https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support
PhotoPrism can only see whatever encoding the host file system and database expose inside the container.

Next step: @s0ren99, please open a terminal session in the PhotoPrism container and inspect the filesystem and locale settings (e.g. locale, mount, and ls -b in the affected directories), and verify the MariaDB charset and collation configuration. That will tell us how the filenames are actually encoded and help pinpoint where the mismatch occurs.

Thanks for the detailed response! Just to clarify: the issue I’m reporting is NOT happening in Library > Originals, where PhotoPrism displays the folder names exactly as they appear on disk.

The problem occurs specifically in Folders view, where PhotoPrism normalizes the display name (capitalizing, removing characters, or treating emoji-named folders inconsistently). For example, a real folder like:

ins/dloralyfo/🪞

shows up in Folders view with the name “Dloralyfo”, which causes conflicts and effectively hides the parent folder and other emoji-named siblings.
Another example:

So the file system itself is fine and the emoji names are correct — it’s the display normalization logic in Folders view that seems to be causing the mismatch.

Just clarifying so the investigation can focus on the Folders view name transformation rather than filesystem encoding.

@s0ren99 commented on GitHub (Dec 6, 2025): > PhotoPrism has full Unicode / UTF-8 support in its database, API, and user interface – emojis and non-ASCII characters in file and folder names should be handled correctly as long as the underlying filesystem uses a compatible encoding: > > <img alt="Image" width="520" height="578" src="https://private-user-images.githubusercontent.com/301686/523267025-be941a9c-e032-4296-9d92-92ad15dc919c.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjUwMTgxNjIsIm5iZiI6MTc2NTAxNzg2MiwicGF0aCI6Ii8zMDE2ODYvNTIzMjY3MDI1LWJlOTQxYTljLWUwMzItNDI5Ni05ZDkyLTkyYWQxNWRjOTE5Yy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMjA2JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTIwNlQxMDQ0MjJaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT01OWYzYmIzMjdiYzhjNjY2OWRhZWQzYzllZjBkNDgzNGY5M2EzMmY3MmUxMDM3ZTg1ZDM1NGUzOWZhN2JkYWQ0JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.ieB-kxxanVRHh8iPav_iqLSbQyItfaJW_fc37mCrVGI"> > The symptoms you’re seeing are most likely caused by the filesystem or mount using a legacy / non-UTF-8 encoding, or by incorrect database charset / collation settings, as described in our MariaDB troubleshooting guide under “Unicode Support”: https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support > > PhotoPrism can only see whatever encoding the host file system and database expose inside the container. > > **Next step:** [@s0ren99](https://github.com/s0ren99), please open a terminal session in the PhotoPrism container and inspect the filesystem and locale settings (e.g. `locale`, `mount`, and `ls -b` in the affected directories), and verify the MariaDB charset and collation configuration. That will tell us how the filenames are actually encoded and help pinpoint where the mismatch occurs. Thanks for the detailed response! Just to clarify: the issue I’m reporting is NOT happening in Library > Originals, where PhotoPrism displays the folder names exactly as they appear on disk. The problem occurs specifically in Folders view, where PhotoPrism normalizes the display name (capitalizing, removing characters, or treating emoji-named folders inconsistently). For example, a real folder like: `ins/dloralyfo/🪞` shows up in Folders view with the name “Dloralyfo”, which causes conflicts and effectively hides the parent folder and other emoji-named siblings. Another example: <img width="434" height="67" alt="Image" src="https://github.com/user-attachments/assets/97d66357-1101-4c5c-a706-0006a9e2916c" /> So the file system itself is fine and the emoji names are correct — it’s the display normalization logic in Folders view that seems to be causing the mismatch. Just clarifying so the investigation can focus on the Folders view name transformation rather than filesystem encoding.

deekerman commented

Author

Owner

@lastzero commented on GitHub (Dec 6, 2025):

I understand that, but I didn't want to flood you with screenshots:

@lastzero commented on GitHub (Dec 6, 2025): I understand that, but I didn't want to flood you with screenshots: <img width="264" height="396" alt="Image" src="https://github.com/user-attachments/assets/0aa957c8-171c-4da9-8e11-60d004c0bb33" /> <img width="1038" height="278" alt="Image" src="https://github.com/user-attachments/assets/afe8bf0e-a98d-4b52-96e8-d04258c43cde" />

deekerman commented

Author

Owner

@lastzero commented on GitHub (Dec 6, 2025):

We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples:

https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support

@lastzero commented on GitHub (Dec 6, 2025): We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples: - https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Dec 6, 2025):

We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples:

https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support

Thanks for your guide.
compose.yaml includes --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci in photoprism and mariadb by default, so I didn't touch them.
I'm not using a DSN.
"XFS always uses UTF-8 internally on Linux"
I have fixed the Locale and ls -b is not displaying "raw UTF-8 bytes" anymore, but it still doesn't fix the folder name issue after a Complete Rescan.

The logs show photos getting updated or new labels:

2025-12-06 20:27:47 INFO index: updated main mp4 file ins/dloralyfo/🐠/2023-12-03...
2025-12-06 20:27:48 INFO index: updated main jpg file ins/dloralyfo/🎃/2023-10-29...

but the folders are simply not appearing in Folders view.

@s0ren99 commented on GitHub (Dec 6, 2025): > We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples: > > * https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support Thanks for your guide. `compose.yaml` includes `--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci` in `photoprism` and `mariadb` by default, so I didn't touch them. I'm not using a DSN. "XFS always uses UTF-8 internally on Linux" I **have fixed** the Locale and `ls -b` is not displaying "raw UTF-8 bytes" anymore, but it still doesn't fix the folder name issue after a `Complete Rescan`. --- The logs show photos getting updated or new labels: ``` 2025-12-06 20:27:47 INFO index: updated main mp4 file ins/dloralyfo/🐠/2023-12-03... 2025-12-06 20:27:48 INFO index: updated main jpg file ins/dloralyfo/🎃/2023-10-29... ``` but the folders are simply not appearing in Folders view.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Dec 7, 2025):

We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples:

https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support

I tested the folder behavior again and the issue is now very clear.

A top-level emoji folder like /🏋🏻 displays correctly as 🏋🏻 in Folders view.

However, an emoji folder inside another folder does not display its actual name. It instead shows the name of its parent folder.
For example:

/ins/🍷 shows up as Ins, not 🍷.

/ins/kate/🥰 shows up as Kate, not 🥰.

So it seems that Photoprism handles emoji folder names correctly only at the root level, but not when the emoji folder is a child directory.

Let me know if you need logs or additional examples. I’m happy to help test. Thanks again for your time!

@s0ren99 commented on GitHub (Dec 7, 2025): > We updated our MariaDB Troubleshooting Guide to provide more accurate advice and detailed examples: > > * https://docs.photoprism.app/getting-started/troubleshooting/mariadb/#unicode-support I tested the folder behavior again and the issue is now very clear. A top-level emoji folder like /🏋🏻 displays correctly as 🏋🏻 in `Folders` view. <img width="91" height="56" alt="Image" src="https://github.com/user-attachments/assets/0c60064e-9a6a-47c3-b7fe-774e205456e0" /> However, an emoji folder inside another folder does not display its actual name. It instead shows the name of its parent folder. For example: /ins/🍷 shows up as Ins, not 🍷. <img width="122" height="56" alt="Image" src="https://github.com/user-attachments/assets/4c980ca3-c4a8-4f10-8b1f-866fd7351499" /> /ins/kate/🥰 shows up as Kate, not 🥰. <img width="168" height="56" alt="Image" src="https://github.com/user-attachments/assets/528ac9e8-9e78-4144-a0d6-438145995527" /> So it seems that Photoprism handles emoji folder names correctly only at the root level, but not when the emoji folder is a child directory. Let me know if you need logs or additional examples. I’m happy to help test. Thanks again for your time!

deekerman commented

Author

Owner

@lastzero commented on GitHub (Dec 7, 2025):

Thanks for the additional information! We'll test it again and provide a fix if reproducible.

@lastzero commented on GitHub (Dec 7, 2025): Thanks for the additional information! We'll test it again and provide a fix if reproducible.

deekerman commented

Author

Owner

@lastzero commented on GitHub (Feb 10, 2026):

@s0ren99 We reproduced and confirmed the issue, which turned out to be a backend lookup bug rather than a filesystem encoding problem. The root cause was that folder albums were resolved by slug or path. Emoji child paths can normalize to the same slug as their parent. For example, ins/🍷 and ins both normalize to ins. This could cause the child folder to resolve/update the parent album entry, making folders appear to be missing or mislabeled in Folders view.

I started a new preview build so you can test this and provide feedback:

Please let us know if it works for you!

@lastzero commented on GitHub (Feb 10, 2026): @s0ren99 We reproduced and confirmed the issue, which turned out to be a backend lookup bug rather than a filesystem encoding problem. The root cause was that folder albums were resolved by slug or path. Emoji child paths can normalize to the same slug as their parent. For example, ins/🍷 and ins both normalize to ins. This could cause the child folder to resolve/update the parent album entry, making folders appear to be missing or mislabeled in Folders view. I started a new preview build so you can test this and provide feedback: - https://docs.photoprism.app/getting-started/updates/#development-preview - https://hub.docker.com/r/photoprism/photoprism/tags?name=preview Please let us know if it works for you!

deekerman commented

Author

Owner

@lastzero commented on GitHub (Feb 11, 2026):

This issue is related and should also be resolved by yesterday's changes:

https://github.com/photoprism/photoprism/issues/5437

The root cause was confirmed to be a folder album slug collision. Different folder paths could normalize/truncate to the same album_slug (80 chars), so one folder album entry could be reused/updated by another path.

@lastzero commented on GitHub (Feb 11, 2026): This issue is related and should also be resolved by yesterday's changes: - https://github.com/photoprism/photoprism/issues/5437 The root cause was confirmed to be a folder album slug collision. Different folder paths could normalize/truncate to the same `album_slug` (80 chars), so one folder album entry could be reused/updated by another path.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Feb 12, 2026):

@lastzero Thank you for the commit! I’ve tested the latest preview build; unfortunately, this issue still persists.

In a directory with multiple emoji-named subfolders like:

~/videos/ins/kelly/
🧩/  ⛱️/  🌸/  Work 😘/

PhotoPrism still seems to struggle with these as It is only picking up two of them.

How I reproduced it:

Moved 🍷 out of /ins
Cleanup
Move 🍷 back in /ins
Folder view shows Ins instead of 🍷

@s0ren99 commented on GitHub (Feb 12, 2026): @lastzero Thank you for the commit! I’ve tested the latest preview build; unfortunately, this issue still persists. In a directory with multiple emoji-named subfolders like: ``` ~/videos/ins/kelly/ 🧩/ ⛱️/ 🌸/ Work 😘/ ``` PhotoPrism still seems to struggle with these as It is only picking up two of them. --- How I reproduced it: - Moved 🍷 out of /ins - Cleanup - Move 🍷 back in /ins - Folder view shows `Ins` instead of `🍷` <img width="341" height="121" alt="Image" src="https://github.com/user-attachments/assets/ad15756c-e651-44c3-b37a-b4b44f384d03" />

deekerman commented

Author

Owner

@lastzero commented on GitHub (Feb 13, 2026):

@s0ren99 Thanks again for testing and providing the reproduction steps! We found and fixed another edge case related to folder names with emojis.

While the previous fix prevented new folder mix-ups, in some situations, an existing folder entry could still have the incorrect title (e.g. showing the parent name instead of the emoji subfolder name). I've now added an additional repair step to automatically correct these stale entries during indexing/updates while keeping edited folder titles intact.

Could you please test the preview build (260213-4a07c1a53) again with your emoji subfolders and the move/cleanup/move-back workflow? If possible, please check cases like 🧩, ⛱️, 🌸, and "Work 😘" as well, and let us know the results.

@lastzero commented on GitHub (Feb 13, 2026): @s0ren99 Thanks again for testing and providing the reproduction steps! We found and fixed another edge case related to folder names with emojis. While the previous fix prevented new folder mix-ups, in some situations, an existing folder entry could still have the incorrect title (e.g. showing the parent name instead of the emoji subfolder name). I've now added an additional repair step to automatically correct these stale entries during indexing/updates while keeping edited folder titles intact. Could you please test the preview build (`260213-4a07c1a53`) again with your emoji subfolders and the move/cleanup/move-back workflow? If possible, please check cases like 🧩, ⛱️, 🌸, and "Work 😘" as well, and let us know the results.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Feb 13, 2026):

@lastzero Thank you again for your build. I've pulled and tested it (260213-postgres), but it still doesn't show the emoji folders correctly or doesn't show it at all:

time="2026-02-13T21:59:19Z" level=info msg="photo: deleted sidecar file ins/🍷/wine-glass_1f377.yml"
time="2026-02-13T21:59:19Z" level=info msg="cleanup: removed ins/🍷/wine-glass_1f377 from index"
time="2026-02-13T21:59:19Z" level=info msg="cleanup: removed 2 index entries and deleted 4 sidecar files [32.865003ms]"
...
time="2026-02-13T22:00:51Z" level=info msg="indexing files in ins"
time="2026-02-13T22:00:52Z" level=info msg="media: generated 6 thumbnails for ins/🍷/wine-glass_1f377.png [125.49138ms]"
time="2026-02-13T22:00:52Z" level=info msg="media: wine-glass_1f377.png was taken at 2025-12-07 16:49:46 +0000 UTC (file mod time)"
time="2026-02-13T22:00:52Z" level=info msg="index: added main png file ins/🍷/wine-glass_1f377.png"
time="2026-02-13T22:00:53Z" level=info msg="index: updated 1 file [1.934083677s]"
...
2026-02-14 06:05:22 INFO index: updated 19 files [2.549232055s]
2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2022-12-12_13.36.08_kelly_GraphStoryVideo_CmEd17OADxx.jpg
2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2024-05-19_14.59.14_kelly_GraphStoryVideo_C7J349CxPTR.jpg
2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2025-02-

@s0ren99 commented on GitHub (Feb 13, 2026): @lastzero Thank you again for your build. I've pulled and tested it (260213-postgres), but it still doesn't show the emoji folders correctly or doesn't show it at all: ``` time="2026-02-13T21:59:19Z" level=info msg="photo: deleted sidecar file ins/🍷/wine-glass_1f377.yml" time="2026-02-13T21:59:19Z" level=info msg="cleanup: removed ins/🍷/wine-glass_1f377 from index" time="2026-02-13T21:59:19Z" level=info msg="cleanup: removed 2 index entries and deleted 4 sidecar files [32.865003ms]" ... time="2026-02-13T22:00:51Z" level=info msg="indexing files in ins" time="2026-02-13T22:00:52Z" level=info msg="media: generated 6 thumbnails for ins/🍷/wine-glass_1f377.png [125.49138ms]" time="2026-02-13T22:00:52Z" level=info msg="media: wine-glass_1f377.png was taken at 2025-12-07 16:49:46 +0000 UTC (file mod time)" time="2026-02-13T22:00:52Z" level=info msg="index: added main png file ins/🍷/wine-glass_1f377.png" time="2026-02-13T22:00:53Z" level=info msg="index: updated 1 file [1.934083677s]" ... 2026-02-14 06:05:22 INFO index: updated 19 files [2.549232055s] 2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2022-12-12_13.36.08_kelly_GraphStoryVideo_CmEd17OADxx.jpg 2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2024-05-19_14.59.14_kelly_GraphStoryVideo_C7J349CxPTR.jpg 2026-02-14 06:05:22 INFO index: updated related jpg file ins/kelly/🌸/2025-02- ``` <img width="347" height="147" alt="Image" src="https://github.com/user-attachments/assets/f1053ef5-c8b6-46f7-b2a8-170d9035e9c4" />

deekerman commented

Author

Owner

@lastzero commented on GitHub (Feb 13, 2026):

The photoprism/photoprism:260213-postgres image was built from a PR/feature branch that does not yet include the fix:

If you are using MariaDB, please test with the photoprism/photoprism:preview image:

PostgreSQL support has not yet been released, so that version/image is expected to contain bugs.

@lastzero commented on GitHub (Feb 13, 2026): The `photoprism/photoprism:260213-postgres` image was built from a PR/feature branch that does not yet include the fix: - https://github.com/photoprism/photoprism/issues/47#issuecomment-3899992658 - https://github.com/photoprism/photoprism/pull/4831 If you are using MariaDB, please test with the `photoprism/photoprism:preview` image: - https://docs.photoprism.app/getting-started/updates/#development-preview - https://docs.photoprism.app/release-notes/#development-preview PostgreSQL support has not yet been released, so that version/image is expected to contain bugs.

deekerman commented

Author

Owner

@s0ren99 commented on GitHub (Feb 13, 2026):

@lastzero My apologies. I've changed it back to photoprism/photoprism:preview and run docker compose up -d --pull always. But docker didn't pull anything new and the emoji folder issue persists.

@s0ren99 commented on GitHub (Feb 13, 2026): @lastzero My apologies. I've changed it back to `photoprism/photoprism:preview` and run `docker compose up -d --pull always`. But docker didn't pull anything new and the emoji folder issue persists.

deekerman commented

Author

Owner

@lastzero commented on GitHub (Feb 13, 2026):

In the page footer under Settings > General, do you see Build 260213-4a07c1a53?

If so, have you tested the move/cleanup/move-back workflow that you described, as well as a complete rescan of the affected folders?

Then, wait about 20 minutes so that the background worker has a chance to run, unless you have configured a longer wakeup interval. You can alternatively run the photoprism moments command in a terminal.

@lastzero commented on GitHub (Feb 13, 2026): In the page footer under Settings > General, do you see `Build 260213-4a07c1a53`? If so, have you tested the move/cleanup/move-back workflow that you described, as well as a [complete rescan](https://docs.photoprism.app/user-guide/library/originals/#when-should-complete-rescan-be-selected) of the affected folders? Then, wait about 20 minutes so that the background worker has a chance to run, unless you have configured a [longer wakeup interval](https://docs.photoprism.app/getting-started/config-options/#indexing). You can alternatively run the `photoprism moments` command [in a terminal](https://docs.photoprism.app/getting-started/docker-compose/#opening-a-terminal).

deekerman commented