mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Video poster image in 'Other' library type gets changed randomly #6774
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jgoguen on GitHub (Feb 27, 2025).
Description of the bug
I have a library with type 'Other'. There's a number of media files in here, all of which are properly detected by Jellyfin when added and they all have a unique poster image generated. After some time, usually within a few hours, all media items are changed to use one poster image. The original poster image is not removed or altered, only the NFO file of every media item is changed to point to one random item's poster image.
As one example, I have 30 media files in the directory
/media/incoming_review, which is in Jellyfin with library type 'Other'. Taking one media file as an example, you can see it has a poster image generated:After importing, this poster image was associated with the media file, it was in the NFO as the poster image, and the poster image was the one displayed in the UI. But after a while, the NFO file now uses a different media file's poster image:
And a quick check shows that every NFO file is now using that same poster image:
I've tried deleting and recreating the directory and library (and copying only
*.mp4and*.info.jsonback into the media folder), I've tried editing each NFO to remove the<poster>node and rescanning the library, and I've used the re-scan option to search for missing metadata and replace all images, and I've used the re-scan option to replace all metadata and replace all images. In all cases, a new poster image is generated and each media file gets a unique poster again, but usually within a couple hours (always within 3 hours) it's reverted back to all media files using the same poster image (of a random media item each time). The original poster image is unmodified on disk, but does not show up when editing the images for any media entry. If I delete the image for a media entry, the poster image from the NFO file is removed so all other media items suddenly show as having no poster image until it's regenerated.Some library configuration notes:
Reproduction steps
What is the current bug behavior?
At random, sometimes after playing media from the library but also sometimes with zero user interaction, the poster images for all media items in a directory are updated to use the same poster image. Not all directories in the library will be affected, and the poster image chosen seems to always be for a media item in the same directory.
What is the expected correct behavior?
Poster images are never changed without direct specific action by the user.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
10.10.6
Specify the build version
10.10.6
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
N/A
Relevant screenshots or videos
No response
Additional information
No response
@jellyfin-bot commented on GitHub (Jun 27, 2025):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@jgoguen commented on GitHub (Jun 27, 2025):
Still an issue, no difference to report
@jellyfin-bot commented on GitHub (Oct 27, 2025):
This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.
If you have any questions you can use one of several ways to contact us.
@jgoguen commented on GitHub (Oct 28, 2025):
Still broken in 10.11.1, no new logs to report
@jgoguen commented on GitHub (Jan 5, 2026):
Still broken in 10.11.5, no new logs to report