Symlinked artwork does not refresh when target file changes #7370

Closed
opened 2026-02-07 04:52:08 +03:00 by OVERLORD · 8 comments
Owner

Originally created by @seblu on GitHub (Sep 29, 2025).

Description of the bug

In a TV show folder, if folder.jpg is a symlink pointing to season1-poster.jpg, Jellyfin does not update the show’s main poster when the target file is changed.

For instance, after setting up the symlink, both the show poster and the Season 1 poster initially display correctly. If I then replace the contents of season1-poster.jpg with a new image and run a metadata refresh, Jellyfin correctly updates the Season 1 poster, but the show poster remains stuck on the old image even though it points to the same updated file. The only way to force an update is to recreate or touch the symlink itself, which is not practical.

Although the issue is easy to reproduce with a folder.jpg pointing to season1-poster.jpg, it is likely more general. Jellyfin seems to detect changes to the symlink itself but not to the file that the symlink points to, which causes inconsistent updates whenever artwork relies on symbolic links.

Reproduction steps

Create a symlink folder.jpg pointing to season1-poster.jpg in a series folder. Let Jellyfin scan the library so both posters are loaded. Update the season1-poster.jpg file by overwriting it with new content while keeping the same filename. Run a Refresh Metadata/Scan for new and updated files on the series.

What is the current bug behavior?

The Season 1 poster updates, but the main show poster remains stale, despite the symlink pointing to the updated file.

What is the expected correct behavior?

Both poster images are updated.

Jellyfin Server version

10.10.0+

Specify commit id

No response

Specify unstable release number

No response

Specify version number

10.10.7

Specify the build version

Release

Environment

- OS: Arch Linux
- Linux Kernel: 6.16-seblu
- Virtualization: None
- Browser: Firefox

Jellyfin logs

There is no log related to refreshing metadata.

FFmpeg logs


Client / Browser logs

No response

Relevant screenshots or videos

No response

Additional information

No response

Originally created by @seblu on GitHub (Sep 29, 2025). ### Description of the bug In a TV show folder, if `folder.jpg` is a symlink pointing to `season1-poster.jpg`, Jellyfin does not update the show’s main poster when the target file is changed. For instance, after setting up the symlink, both the show poster and the Season 1 poster initially display correctly. If I then replace the contents of `season1-poster.jpg` with a new image and run a metadata refresh, Jellyfin correctly updates the Season 1 poster, but the show poster remains stuck on the old image even though it points to the same updated file. The only way to force an update is to recreate or touch the symlink itself, which is not practical. Although the issue is easy to reproduce with a `folder.jpg` pointing to `season1-poster.jpg`, it is likely more general. Jellyfin seems to detect changes to the symlink itself but not to the file that the symlink points to, which causes inconsistent updates whenever artwork relies on symbolic links. ### Reproduction steps Create a symlink `folder.jpg` pointing to `season1-poster.jpg` in a series folder. Let Jellyfin scan the library so both posters are loaded. Update the `season1-poster.jpg` file by overwriting it with new content while keeping the same filename. Run a `Refresh Metadata/Scan for new and updated files` on the series. ### What is the current _bug_ behavior? The Season 1 poster updates, but the main show poster remains stale, despite the symlink pointing to the updated file. ### What is the expected _correct_ behavior? Both poster images are updated. ### Jellyfin Server version 10.10.0+ ### Specify commit id _No response_ ### Specify unstable release number _No response_ ### Specify version number 10.10.7 ### Specify the build version Release ### Environment ```markdown - OS: Arch Linux - Linux Kernel: 6.16-seblu - Virtualization: None - Browser: Firefox ``` ### Jellyfin logs ```shell There is no log related to refreshing metadata. ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs _No response_ ### Relevant screenshots or videos _No response_ ### Additional information _No response_
OVERLORD added the bug label 2026-02-07 04:52:08 +03:00
Author
Owner

@tjwalkr3 commented on GitHub (Oct 15, 2025):

I would like to take a crack at fixing this bug if nobody else has started working on it.

@tjwalkr3 commented on GitHub (Oct 15, 2025): I would like to take a crack at fixing this bug if nobody else has started working on it.
Author
Owner

@theguymadmax commented on GitHub (Oct 15, 2025):

This needs to be tested on 10.11/Master if the issue exists. There are no more planned 10.10.x releases.

@theguymadmax commented on GitHub (Oct 15, 2025): This needs to be tested on 10.11/Master if the issue exists. There are no more planned 10.10.x releases.
Author
Owner

@tjwalkr3 commented on GitHub (Oct 15, 2025):

I just tested it on master, and I was able to reproduce the bug.

@tjwalkr3 commented on GitHub (Oct 15, 2025): I just tested it on master, and I was able to reproduce the bug.
Author
Owner

@tjwalkr3 commented on GitHub (Oct 24, 2025):

I couldn't figure out how to fix this. If anybody else wants to take a crack at it, they can.

@tjwalkr3 commented on GitHub (Oct 24, 2025): I couldn't figure out how to fix this. If anybody else wants to take a crack at it, they can.
Author
Owner

@seblu commented on GitHub (Oct 24, 2025):

I couldn't figure out how to fix this. If anybody else wants to take a crack at it, they can.

Could you point the function which check if the files have to be updated?

@seblu commented on GitHub (Oct 24, 2025): > I couldn't figure out how to fix this. If anybody else wants to take a crack at it, they can. Could you point the function which check if the files have to be updated?
Author
Owner

@tjwalkr3 commented on GitHub (Oct 25, 2025):

It's the MergeImages function in MediaBrowser.Providers.Manager.ItemImageProvider (around lines 454-463). It checks whether the current date modified is equal to the new date modified. When it does this for a symlink, it isn't checking the modified date of the file that the symlink points to, it's checking the symlink itself.

@tjwalkr3 commented on GitHub (Oct 25, 2025): It's the MergeImages function in MediaBrowser.Providers.Manager.ItemImageProvider (around lines 454-463). It checks whether the current date modified is equal to the new date modified. When it does this for a symlink, it isn't checking the modified date of the file that the symlink points to, it's checking the symlink itself.
Author
Owner

@Shadowghost commented on GitHub (Oct 25, 2025):

@tjwalkr3 @seblu feel free to check out my PR if it solves the issue (I don't have symlinked stuff, so I can't really test this)

@Shadowghost commented on GitHub (Oct 25, 2025): @tjwalkr3 @seblu feel free to check out my PR if it solves the issue (I don't have symlinked stuff, so I can't really test this)
Author
Owner

@theguymadmax commented on GitHub (Oct 27, 2025):

Fixed by #15209

@theguymadmax commented on GitHub (Oct 27, 2025): Fixed by #15209
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#7370