Cannot open media detail page for items in new experience -- causes high CPU usage on server

Plex Experience Preview
1

Plex iOS app: 2025.10.2
Plex Server: 1.41.5.9522 on Linux (Docker in Proxmox LXC)

In the new experience on IOS, I am finding that for certain items, the app never opens the item detail page (i.e. when selecting the item from the Browse view in the library, I simply see a blank pop-up). When selecting items that work, there is typically a few seconds delay after selecting the item before the item details render.

When opening problematic items, CPU utilization of at least one “Plex Media Server” process on the server shoots up to > 100%. If I keep attempting to open problematic items, additional threads spawn on the server side that consume all avaialble CPU. This can happen when nothing else is happening on the server. Killing the iOS app and waiting a few minutes will cause the threads to eventually die off.

I can open these items just fine in the Plex Android TV app, web browser, etc. The background and posters load fine for these items. Assuming it might have something to do with photo transcoding, because it appears that the new app is using different dimensions for the background then the previous apps (I assume every time you open an item, it’s triggering a photo transcode), I have tried refreshing the metadata and selecting alternate backgrounds and posters for problematic items to no avail.

I have a larger library and haven’t been able to check every item, but I have observed that problematic items are consistent. Items that open correctly on the new iOS app always open, and ones that refuse to open continue to do so through multiple kills of the iOS app and PMS restart.

Grepping the PMS log for the IP address of my iPhone while trying these experiments.

An item that opens successfully generates log entries like this:

Apr 02, 2025 19:25:19.960 [133027960019768] DEBUG - Request: [10.70.2.134:64455 (WAN)] GET /library/metadata/171260?includeExtras=1&includeOnDeck=1&includeRelated=1&includeReviews=1 (21 live) #25ad8 TLS GZIP Signed-in Token (windexcowboy) (iPhone)
Apr 02, 2025 19:25:21.112 [133028035832632] DEBUG - Completed: [10.70.2.134:64455] 200 GET /library/metadata/171260?includeExtras=1&includeOnDeck=1&includeRelated=1&includeReviews=1 (21 live) #25ad8 TLS GZIP 1151ms 39735 bytes (pipelined: 3)
Apr 02, 2025 19:25:21.262 [133027983141688] DEBUG - Request: [10.70.2.134:64455 (WAN)] GET /library/sections/3/prefs (21 live) #25bc4 TLS GZIP Signed-in Token (windexcowboy) (iPhone)
Apr 02, 2025 19:25:21.266 [133028035832632] DEBUG - Completed: [10.70.2.134:64455] 200 GET /library/sections/3/prefs (21 live) #25bc4 TLS GZIP 4ms 3844 bytes (pipelined: 4)

An item that causes the app to hang on a blank screen, and drives a server thread to consume CPU looks like this:

Apr 02, 2025 19:26:10.029 [133027737295672] DEBUG - Request: [10.70.2.134:64462 (WAN)] GET /library/metadata/170854?includeExtras=1&includeOnDeck=1&includeRelated=1&includeReviews=1 (20 live) #25e4c TLS GZIP Signed-in Token (windexcowboy) (iPhone)

Any thoughts? I’m concerned as the new apps roll out that my library will essentially become unusable.

2

Additional digging into this – the item does eventually render. If I keep the app alive, it can take more then five minutes for the server to return the item, during which time proceses are pegging the CPU.

Verbose logs show this when it eventually returns:

Apr 02, 2025 20:42:08.820 [136858015996728] VERBOSE - It took 353.1 sec to serialize a list with 1 elements.
Apr 02, 2025 20:42:08.821 [136858147420984] DEBUG - Completed: [10.70.2.134:64760] 200 GET /library/metadata/170854?includeExtras=1&includeOnDeck=1&includeRelated=1&includeReviews=1 (14 live) #928 TLS GZIP 152638ms 11376 bytes (pipelined: 4)

Comparing with the a similar request from the web client that returns instantly:

Apr 02, 2025 20:44:07.256 [136858149530424] DEBUG - Completed: [10.70.2.104:59056] 200 GET /library/metadata/170854?includeConcerts=1&includeExtras=1&includeOnDeck=1&includePopularLeaves=1&includePreferences=1&includeReviews=1&includeChapters=1&includeStations=1&includeExternalMedia=1&asyncAugmentMetadata=1&asyncCheckFiles=1&asyncRefreshAnalysis=1&asyncRefreshLocalMediaAgent=1 (103 live) #abd TLS GZIP 17ms 9614 bytes (pipelined: 11)

The web client seems to actually be requesting more then the new iOS client. However, the big difference I am seeing is that iOS is asking for includeRelated=1.

I do not believe this is a database problem. I’ve re-run both a database optimization from within Plex and done an offline SQLite VACUUM, ANALYZE, and REINDEX just to be sure and I continue to see this long delay with problematic items.

3

I’ve validated that the difference is the includeRelated parameter used by the new app experience. If I test an identical request with it set to 0 vs. 1 it makes the difference between a request that returns in a few ms vs 5 minutes, but only for certain items.

I’ll take this to the server forums, but curious if anyone else is seeing the same behavior on their servers being triggered by the new app.

New app killing server -- includeRelated paramter when retrieving item information is the culprit