I do not think they will fix it, but ill still add my +1, i just lost DAYS worth of work and most if not all of the posters were locked. So even locked does not matter, dont let them fool you.
1 Like
Not until we have steps to reproduce. So far the two scenarios that user’s asked us/me to test has not successfully reproduce the issue that is reported here.
I’ve had this scenario setup for many months (is still setup) with many many PMS version changes (both downgrading and upgrading). No changes to posters that were confirmed locked.
I wasn’t able to get this environment matched 1:1 but as you can see this user had left the forums so I wasn’t able to get any additional information. I did replicate their setup as best as I could and still could not reproduce the issue.
If you have some solid steps that reproduce the issue, please share them. This is why this thread has gone on for so long. We do not have steps to reproduce. If our field locking isn’t working as it’s being reported then a global lock won’t do much good. Regardless, both the request for a UI element that would more clearly show that the poster/art is locked (similar to other fields) and a setting for a “global” lock action have internal issues created. No ETA yet on either.
To clarify… I asked to have my previous forum account removed. I’d given you my db, logs and extremely detailed steps on exactly how to repro at least one version of this problem. I reached out to you one additional time (approx 1 month after after giving you this information) and you said you had not looked at it at that time. Months then passed and I heard nothing …
If you’d like, could we pick up where we left off? Happy to start another DM or continue it here.
Just an update over a year later since running my script.
All posters are still 100% locked. No posters have unlocked themselves.
I can’t comment on if the actual posters images have remained unchanged (i.e. poster is locked but still changed) because I didn’t keep track of that, but at least the lock flag works.
Edit: I have now saved a hash for all the posters. Will report back in another year.
2 Likes
Thank you, @Atomatth …
Evidence? The number of users who claim to have a problem is a clear indication.
Why not just implement a user-controlled lock for these posters but insist on software-ai-style lock without user control?
I just don’t get it. Please explain.
There are plenty of scenarii (provider changes, server software changes) that happened in the past that led to unwanted change of the graphical metadata.
Put the poster-loving users in the driver’s seat of what’s important to them regarding user experience.
I am NOT saying that there is an actual code problem that needs to be fixed. I cannot say. But since the poster is an important UI introduction element of any movie or tv show, you should think about just following the demand for control. A poster defines the first impression of a movie or TV show in library view, in home… everywhere. I creates interest, shapes uniformity or diversity… it is just an important element.
Or just give us a global lock and be done with this mummer’s farce? Perhaps revisit the real root cause later once we are ready to downgrade TV posters to gracenote?
One can think that there are far more pressing issues to tackle for paying customers.
I can appreciate the bug hunting exercise, but even with that milestone payment received at end of Q1 for MVP, we all know talented engineering resources post-reorg are beyond stretched thin. Take the easy win and move on to actual issues that require thinking?
So, two critical questions as I can repro this 100% of the time using the steps I outlined about.
- do you use local assets ?
- does your media change its location/name requiring a re-scan to re-map it.
Anyhow, let me yet again outline the exact steps I included above previously which I re-validated this morning.
Lets take this movie …
Notice the poster & fanart. Here is exactly how the files are named on disk …
[mcurran]-[dokuro]:/data/Personal/Scripts$ ls -la "/data/MediaServer/14b-Movies/Movies from -> 0-D/Arthur and the Invisibles {tmdb-9992}/"
total 1827260
drwxr-xr-x 3 501 mcurran 4096 Apr 16 09:34 .
drwxr-xr-x 882 501 mcurran 65536 Apr 16 09:34 ..
-rw-r--r-- 1 501 mcurran 122620 Apr 16 08:38 'Arthur and the Invisibles [1080p AVC].eng.srt'
-rw-r--r-- 1 501 mcurran 1869579623 Apr 16 08:38 'Arthur and the Invisibles [1080p AVC].mp4'
-rw-r--r-- 1 501 mcurran 694602 Apr 16 08:38 fanart.jpg
-rw-r--r-- 1 501 mcurran 633818 Apr 16 08:38 poster.jpg
drwxr-xr-x 4 501 mcurran 4096 Apr 16 08:38 .xattr
[mcurran]-[dokuro]:/data/Personal/Scripts$
Now, lets simulate a change by adding (2006) year to this name of the folder and media, thus rename to this …
[mcurran]-[dokuro]:/data/Personal/Scripts$ ls -la "/data/MediaServer/14b-Movies/Movies from -> 0-D/Arthur and the Invisibles (2006) {tmdb-9992}"
total 1827260
drwxr-xr-x 3 501 mcurran 4096 Apr 16 09:42 .
drwxr-xr-x 882 501 mcurran 65536 Apr 16 09:41 ..
-rw-r--r-- 1 501 mcurran 122620 Apr 16 08:38 'Arthur and the Invisibles (2006) [1080p AVC].eng.srt'
-rw-r--r-- 1 501 mcurran 1869579623 Apr 16 08:38 'Arthur and the Invisibles (2006) [1080p AVC].mp4'
-rw-r--r-- 1 501 mcurran 694602 Apr 16 08:38 fanart.jpg
-rw-r--r-- 1 501 mcurran 633818 Apr 16 08:38 poster.jpg
drwxr-xr-x 4 501 mcurran 4096 Apr 16 08:38 .xattr
[mcurran]-[dokuro]:/data/Personal/Scripts$
Scan the library for changes and its all changed to this …
Notice the poster has changed and the fanart is removed. Movie is correctly matched, its just all the custom artwork is messed up. At this point they are broken and no matter how many times you refresh the metadata the local assets are NEVER picked up.
As a workaround you need to edit the movie, select the poster tab and then background tab (without changing anything) and then close the editor. Once you do this you can successfully force refresh the movie and the correct artwork is then picked up.
Is this the same situation that is happening for others reporting poster changes, maybe not but this exactly scenario as I outlined above is consistent and does result in missing/changed artwork. Maybe if this is fixed it’ll fix the other occurrences …
I’ve also a DM going with @Atomatth
2 Likes
Until then, users can set their libraries to use local assets (though @dokuro may disagree 
) or there are several community created solutions to go through your library and lock posters or any other fields.
1 Like
Nope, I’d 100% agree. Local assets is they way to go and gives admins way better control of artwork.
1 Like
This is the way. 
Stop using the Web UI to select your posters and use local assets.
- poster.jpg
- background.jpg
- theme.mp3 (hope it’s not been deprecated)
- and really looking forward clearlogo.png support.
2 Likes
It’s only been a year since the request for a global lock. At least there might be some traction and look forward to asking about it in Q1 2026 fireside chat.
Although I appreciate pointing to scripts that fix Plex’s broken poster system, I have less than zero idea what to do with those links. Paying customers shouldn’t have to learn how to program.
Perhaps it’s a good time to learn how to run scripts. You’re not asked to learn how to code.
Personally I picked up Plex to automate this stuff so I didn’t have to manage local assets myself, which was a big part of their reason for paying for the platform, but recent changes with Plex make it so I likely have to even without this specific issue; DCMA removes all art for a title now for example and licensed art is often not the art I - or community voting - would have picked as quality option.
I support the “lock” option as a way to let folks have an option that resolves things and lets admins have more local control no matter if there’s a bug or not (outside of @dokuro specific example which seems like deserves a fix). People who want to make sure their art stays exactly as it’s picked can lock it as they go and those that aren’t experiencing any issues or don’t care or see the changing art as a feature can leave it alone just like they do with the editable and lockable text fields.
That option would also address the DMCA removing all art because if it’s locked that’s a user side thing and Plex can still say “been removed from server side”.
Just a thought anyways from someone who uses Plex because it’s automated for me allowing me to be lazy about it. 
If you do something similar, but without modifying the file name (just update the path), do you see the same behavior?
I ask because I did a quick experiment here where I moved a movie I didn’t have in its own sub-directory into one, but left its filename as-is. After a scan the behavior was that just the path was updated in the database (it kept the same media parts info and metadata).
I then just added the year to the filename. This caused it to be re-detected after a scan. Its watch history and date added were maintained. However, it got a new ratingKey and all of its media parts were updated to reflect it (the re-detection). Its metadata was all updated to reflect the new ratingKey as well.
Before (ratingKey 4280):
After (ratingKey 20208):
It also lost all of its deep analysis information due to the filename change.
All of that to say, I think changing the filename triggers enough of a change to cause that specific instance to lose its customizations while information related to the movie itself (when it was first added to your library and its watch history) are maintained. So, from the outside, it looks like it’s the same library entry. But it’s really a new instance of the same movie.
1 Like
Me with absolutely zero programming experience: running scripts is literally the same as learning to code.
I have less than zero idea what to do, as a paying customer, with the github link to fix plex’s broken (on purpose) server.
“I’m a paying customer” has no value here. Take that somewhere else where it might work, lol.
1 Like
Just changing the folder which the movie is in resulted in the same behaviour. Poster changed and background missing. Checking the xml you can clearly see this and also see that background is missing.
Before:
<Image alt="Arthur and the Invisibles" type="coverPoster" url="/library/metadata/413195/thumb/1744796956"/>
<Image alt="Arthur and the Invisibles" type="background" url="/library/metadata/413195/art/1744796956"/>
<Image alt="Arthur and the Invisibles" type="clearLogo" url="/library/metadata/413195/clearLogo/1744796956"/>
After:
<Image alt="Arthur and the Invisibles" type="coverPoster" url="/library/metadata/413216/thumb/1744796956"/>
<Image alt="Arthur and the Invisibles" type="clearLogo" url="/library/metadata/413216/clearLogo/1744796956"/>
I think it’s the changing of the item used in matching which is important. For me, it’s the folder but for you it might be file depending on how you have setup your media & library.
Does that matter ? The movie is matched correctly and plex should map it and use the artwork and/or local assets associated with the entry. These are broken by this scenario.
Again, folks are trying to find repeatable steps on why artwork is changing. Here it is. Now plex need to go fix this.
2 Likes
Yep, I understand. I’d hoped that this would help narrow it a little further to something even a little more specific. In my (admittedly single) test, just changing the folder name didn’t trigger the change; I had to change the file name as well.
I think it might, if there are different root causes or even different issues. I didn’t convey it well, but what I was trying to get across is that I think that, at least in this specific case, we may be seeing the intended, if undesired, behavior. That since entirely new media parts are being created and the ratingKey is re-generated, that we’re actually dealing with a new instance of the movie. Not the old instance being updated. Hence the changed metadata.
Reading through the thread, I got the impression that what many folks are seeing is a spontaneous updating of movies’ posters after having made no changes at all.
And for what it’s worth, overnight deep analysis was performed on my “new” Jeepers Creepers instance. Also, I did notice the missing background metadata on my side as well. That was because I don’t use the feature (but I did at one point). As soon as I re-enabled it the background was shown in the XML info, with the same timestamp as the other items. So it was available, just unselected.
I’m not sure a global lock is going to work if the underlying problem, at least in this case, is that a new instance of the movie is being created due to filesystem changes. I don’t think it will be enough to lock the data in that case. It will have to be persisted (and locked), like the view history and date added timestamp.
Anyway, I understand folks are frustrated and I don’t mean to add to it. Just hoping to understand the problem(s) a little better. I used your steps as a starting point because they’re reproducible, not as an attempt to refute your findings. Please feel free to ignore my theory-crafting.
1 Like
Hopefully there is a fix for this eventually. Plex always manages to change it to the ugliest poster art lol
3 Likes
