Certain Default Artist Images Kill my Plex Server

Hey everyone!

I’ve been working on a fun little side project: a custom PHP script to scrape my films, tv shows and the music library and generate a static website. It’s been great, but I hit a head scratcher.

I think I’ve narrowed down a bug that causes my entire Plex Media Server process to crash and terminate when trying to grab the default artwork for just a few specific artists.

I initially thought I was just overloading the API, but after days of debugging, I’ve confirmed the issue is tied to the source image file itself that Plex is attempting to process.

When my script asks PMS to resize an image, it uses the standard transcoder endpoint: /photo/:/transcode

When it hits one of the “killer images,” the entire Plex server goes offline. My script just gets an immediate disconnect error: HTTP Code: 0. Curl Error: Empty reply from server. This means the server process completely died before it could even send an error code!

These are the default artist images that consistently crash PMS in my library when my script tries to resize them:
Dire Straits
Carpenters
Creedence Clearwater Revival
Eurythmics
Eagle-Eye Cherry

(5 out of 236 artists)

I built a tiny script that only requests the problematic image path once, proving it wasn’t a concurrency or overload issue — the image(s) themselves are possibly corrupt?!

I tried the full “Plex Dance” (remove media, scan, empty trash, optimise database, re-add media, scan). The new metadata came back, but when my script ran again, it crashed again!

For one of the artists, I located the actual high-res source file in the metadata folder. The one that causes the crash is tv.plex.agents.music_657fdd9b92dc43913aa79ad80c1e04fe74a990c0. I can confirm that a healthy file (e.g., tv.plex.agents.music_01eac8cd4ac5bc9cdbc4166cd308151e23d60c29) works perfectly fine.

I have worked around it manually by changing the artist’s image to the “second option”, this instantly resolves the crash.

I am attaching the server debug just in case anyone is interested :grinning_face:

Plex Media Server.1.log (62.0 KB)

Plex Tuner Service.1.log (2.7 KB)

Server Version: 1.43.0.10231 (Just so you know!)

1 Like

Have you tried using some kind of image utility to verify the image?

If a corrupt image is provided by Plex’s official metadata I would hope they’d be game for fixing it on their side.

I have just completed an exiftool comparison.

I took 3 artist images that I know break the plex server for me and compared them against 3 of their other images that don’t. I placed the results in to AI (quicker than me making the comparisons) and when I asked it to compare the images that were breaking the plex server on api calls vs those that weren’t it came back with:

All three images that break Plex are consistently structured as monochrome (Grayscale) JPEGs,

The three images that broke Plex were:

  1. tv.plex.agents.music_83ab46dd8ad59da8c2a7043cf255887f2878e546

  2. tv.plex.agents.music_12184e303555ea962c177e772aa8963a22572737

  3. tv.plex.agents.music_657fdd9b92dc43913aa79ad80c1e04fe74a990c0

They all share the following core metadata tags, which classify them as non-standard for typical poster artwork:

Metadata Field Value in ALL Breaking Images Standard (Working) Value
Color Components 1 3
Color Mode (XMP) Grayscale RGB or YCbCr
Photometric Interpretation BlackIsZero RGB or YCbCr
1 Like

Could you supply the script and a copy of the image(s)?

I don’t see this behaviour with our default calls to the photo transcoder (with my Dire Straits image) so it sounds like something to do with how your script is invoking it.

Thanks drzoidberg33.

Let’s go with Dire Straits, I have attached 2 images. One that works and the other crashes the server.

fails = tv.plex.agents.music_3aa127ee1a12df3490fb812f87eeeed3cc6fd008

success = tv.plex.agents.music_89e8e3d5400d8fd3196de4c984b209276c84e9d8

I have attached a test script that I used to against the api and this will crash the server when the band/artist image is 3aa127ee1a12df3490fb812f87eeeed3cc6fd008

set the artist details in the script:
const TARGET_THUMB_PATH = ‘/library/metadata/19710/thumb/1762897129’;

then call the script:
php single_image_extract.php plexip:port

you should get a debug file: single_extract_debug.log

Fail Image:
21:42:21 - DEBUG: Attempting Image Transcode/Download for: 95f62556ff609612ce0cc7b2c8ced954.webp from ‘/library/metadata/19710/thumb/1762897288’
21:42:21 - DEBUG: Attempting API Call. Endpoint: ‘/photo/:/transcode?width=300&height=450&minSize=1&url=%2Flibrary%2Fmetadata%2F19710%2Fthumb%2F1762897288&X-Plex-Token=<API_KEY>&format=webp’. URL: ‘http://<PLEX_SERVER_IP:PORT>/photo/:/transcode?width=300&height=450&minSize=1&url=%2Flibrary%2Fmetadata%2F19710%2Fthumb%2F1762897288&X-Plex-Token=<API_KEY>&format=webp’.
21:42:22 - ERROR: Plex API FAIL. HTTP Code: 0. Curl Error: Empty reply from server. Response was: FALSE

Success Image:
21:40:10 - DEBUG: Attempting Image Transcode/Download for: f4b2ca4bbba691ba0d4055743398e521.webp from ‘/library/metadata/19710/thumb/1762897129’
21:40:10 - DEBUG: Attempting API Call. Endpoint: ‘/photo/:/transcode?width=300&height=450&minSize=1&url=%2Flibrary%2Fmetadata%2F19710%2Fthumb%2F1762897129&X-Plex-Token=<API_KEY>&format=webp’. URL: ‘http://<PLEX_SERVER_IP:PORT>/photo/:/transcode?width=300&height=450&minSize=1&url=%2Flibrary%2Fmetadata%2F19710%2Fthumb%2F1762897129&X-Plex-Token=<API_KEY>&format=webp’.
21:40:10 - DEBUG: Image Downloaded: f4b2ca4bbba691ba0d4055743398e521.webp.

when successful then the new image outputs to:./single_image_output

single_image_extract.txt (5.8 KB)

I see you’re trying to use webp as a transcode target, unfortunately we don’t officially support that as it was found to be unreliable (as you’ve discovered).

This will eventually get fixed when we move over to a different image processing library.

Here are the officially supported formats: https://developer.plex.tv/pms/#tag/Transcoder/operation/imageTranscode

Thank you. I appreciate webp is not listed as a officially supported format (but it kind of worked :slight_smile: ).

What I have now tried instead of webp is AVIF, and that looks to be more robust and is holding strong, when converting.. again I appreciate it is not a supported format but it seems to be working.

Are we sure we are looking at exactly the same images OP used? If they were posted to the forum, the forum may have processed them, right? Should OP post a zip, or checksums of his files?

It doesn’t matter, the issue is with converting to webp.

when I change the code from webp to jpeg it works with the images that were causing the server to crash. I wanted something a bit more modern than jpeg.

As mentioned, I have changed to using AVIF instead and that is working fine with the images I was having issues with but I am also outputting jpeg as well and using that for fallback in case any browser that I use does not support AVIF .

I appreciate AVIF is not a supported format but it is working for me at the moment.

I haven’t tried running Jpeg XL against the API yet :wink: