mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Some custom primary images/art seem to have automatically reverted or replaced with defaults #3321
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 @retroNUC on GitHub (Oct 17, 2021).
Describe the bug
System (please complete the following information):
Screenshots
In case it helps with parsing logs:
Server Logs
Attached from the past three days, although from a quick search of titles that have been affected, it seems to have happened before the automatic 3-day clean-up period, so probably not useful. I've disabled the clean-up task, so will have more useful info if the issue happens again.
jellyfin_logs.zip
Apologies in advance that the info in this bug may not be useful enough to identify/debug the issue. I'll keep an eye out to see if the issue occurs again in the future.
@qsniyg commented on GitHub (Jan 29, 2022):
I can confirm. In my case, if I edit the images too soon after the media has been uploaded, it will automatically change back in a few minutes. Otherwise it tends to stay.
@Avamander commented on GitHub (Jun 26, 2022):
I'm seeing the same thing, shouldn't images be replaced only if a manual scan is initiated with the option? Why should the WebUI offer an option to replace the image if it knows it's configured to replace them automatically?
@zang74 commented on GitHub (Jun 29, 2022):
Can confirm it's still happening with 10.8.1.
Custom movie Poster image is set, Item is locked to prevent future changes and it still reverts to the poster with the highest votes.
@lazi3b0y commented on GitHub (Jul 17, 2022):
I seem to experience problems when Scanning All Libraries under Dashboard. Running 10.8.1.
Some of my movies has a jpg in the same folder as the movie file, and every time I use Scan All Libraries (note not refresh metadata, and not with the option to replace all metadata) it reverts the primary art back to the one in the folder.
@qsniyg commented on GitHub (Jul 23, 2022):
To add another issue, which I believe is related: If Jellyfin identifies the wrong movie and I re-identify the film correctly (soon after the film was first added), it will sometimes (but not always) revert to the old one, even if I lock the item to prevent future changes. It seems to revert in the same frequency/manner that images are reverted, which leads me to believe that this issue has to do with the film's metadata (including images) being reset.
@madoka315 commented on GitHub (Sep 22, 2023):
Same issue still exists today. Tried checking "Lock the metadata" but didn't work.
@dantiberi commented on GitHub (Sep 26, 2023):
I have experienced this issue in 10.8.1 but only with specific music albums. One such album keeps reverting to an image from a different album with a similar name.
@fabwa commented on GitHub (Oct 10, 2023):
still happening
@Arsur commented on GitHub (Oct 15, 2023):
I have the same problem
@fffrankieh commented on GitHub (Dec 10, 2023):
This happens to me with movies. Periodically when I am browsing movies, I notice one or more with an unfamiliar poster, when I know I had set a different poster on it through the web UI weeks or months or even years before.
Sometimes too, on movies that were wrongly identified when they were first added to the library, again maybe even years ago, the poster and all the metadata reverted to the wrong movie.
I also have "Automatically refresh metadata from the internet" set to "Never" on all libraries. Metadata is not stored in NFO files. Images are stored in media folders alongside the media.
@sjorge commented on GitHub (Jan 7, 2024):
Do you guys perhaps have a poster.jpg in the media's directory too?
My media mounted RO, if I replace a poster (that was loaded from poster.jpg) it will never stick. It seems to me that a poster.jpg on disk will always take priority on any kind of scan.
@ryco117 commented on GitHub (Jan 8, 2024):
This turned out to be the exact issue for me. Not sure if this should be considered a bug or intended behavior, but it sure seems counter-intuitive that the jellyfin-configured image has less precedence than what is beside the media on-disk.
@sjorge commented on GitHub (Jan 8, 2024):
Yeah it was certainly a surprise to me.
It would be nice it
local assetsor something was a provider under the library settings so we could uncheck and/or change the priority.Not sure that’s feasible to implement though.
@jellyfin-bot commented on GitHub (May 7, 2024):
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.
@qsniyg commented on GitHub (May 7, 2024):
Still an issue. My guess is that an internal ID is changed in some cases, so it's replaced by a "new" item with a different ID. This would explain my related issue here: https://github.com/jellyfin/jellyfin/issues/6709#issuecomment-1192992412
@jellyfin-bot commented on GitHub (Sep 5, 2024):
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.
@qsniyg commented on GitHub (Sep 13, 2024):
Just confirmed this issue is still present on 10.9.7, I'll have to test later on 10.9.11.
@dorkbuttt commented on GitHub (Sep 18, 2024):
I'm using 10.9.11 and if anything it looks like it changes them back faster. I have the option disabled. Should I post logs?
@ghost commented on GitHub (Oct 21, 2024):
On the last version and still same issue.
@Chestnut7 commented on GitHub (Nov 4, 2024):
Experiencing same issue with latest version as of today's date, multiple shows keep having artwork replaced even though metadata is locked
@Punctual-Donkey commented on GitHub (Nov 9, 2024):
I've been experiencing this same problem as well, Jellyfin version 10.10.1. I have a series with a "folder.jpg" image that I uploaded as the "primary" image. And while the folder.jpg image remains the correct one, the primary image for the series keeps getting replaced. I have to choose "edit images", delete the bad one, and re-upload "folder.jpg" as the primary again.
Edit: I thought this was Jellyfin's fault, but it turns out the problem was Sonarr (v4.0.10.2544) - it kept forcing its own "primary" image into the Jellyfin series. I disabled all image metadata in Sonarr, and the problem went away.
@dorkbuttt commented on GitHub (Nov 15, 2024):
@Punctual-Donkey That was precisely the cause of my issue as well. I am not very attentive to the settings I have access to..
@sbkg0002 commented on GitHub (Feb 22, 2025):
Thanks for the edit; which setting is responsible for this?
@Punctual-Donkey commented on GitHub (Feb 23, 2025):
Via the Sonarr web interface, go to Settings->Metadata->Kodi (XBMC) / Emby (It doesn't list Jellyfin, but you are probably aware Jellyfin is a fork of Emby). On this settings page, you can enable and disable various forms of metadata, with a master "Enable" switch at the top. In my case, I have the master metadata switch enabled, with settings "series metadata" and "episode metadata" turned on, but "series images", "season images", and "episode images" turned off. That way I get all the textual metadata details from Sonarr, but I leave the images purely to Jellyfin, and I can better control the images and quiet my OCD. :)
@fahminlb33 commented on GitHub (Mar 7, 2025):
I also experienced the same image problem in 10.9.11. What worked for me is disabling Metadata saver > NFO in the Libraries menu. After I unchecked it, the poster is no longer reverting to previous image.
@Punctual-Donkey commented on GitHub (Mar 7, 2025):
That makes sense.
As I understand the nfo setting, it's telling Jellyfin to both read and write metadata into ".nfo" files in the same folder with your media, rather than from its own internal database. This has the benefit of making metadata more portable with your media, separate from a specific Jellyfin install. Also of note, if the nfo setting is on, Jellyfin will prefer metadata from the local nfo file rather than fetching from one of the internet metadata providers, if the specific data is present in the nfo file. You can open an nfo file in a text editor and pretty easily read and modify it yourself, it's just basic XML.
If some other software (for example, something like Sonarr) is both copying an image file into your media folder, and then writing an "nfo" file with it, the nfo file will contain a pathname to the image file it wrote. Jellyfin will read the pathname to the image from the nfo file and then use that image, ignoring its own database. So in this case, turning off the nfo checkbox will solve the problem of some other software writing .nfo files and alternate images into your media folders; Jellyfin will ignore that data and use its own database. In this situation your drive still has the "wrong" images being stored in your media folders, but Jellyfin won't use it.
At least that's my understanding of all this. Much appreciated if a Jellyfin dev confirms or corrects me about this.
@jellyfin-bot commented on GitHub (Jul 6, 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.
@qsniyg commented on GitHub (Jul 6, 2025):
Still happens on 10.10.3. I'll try later with 10.10.7.
@pl98 commented on GitHub (Oct 19, 2025):
I still experience this on 10.10.7. I have all the metadata settings disabled in Radarr/Sonarr and NFO saver disabled as well. I have the option to save images to disk enabled, but this doesn't seem to prevent Jellyfin from replacing the existing file with a new one when something gets upgraded.
@briantho2010 commented on GitHub (Jan 14, 2026):
Confirmed images are still being overwritten with on disk jpg’s on 10.11.5. NFO and metadata refreshes are disabled but posters get overwritten once a day.
@myt960 commented on GitHub (Feb 1, 2026):
I have the same issue (10.11.6)