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

Plex Media Server
1

Server Version#: 1.41.5.9522 - Linux (Docker in Proxmox LXC)
Player Version#: iOS 2025.10.2 and Web

I started a thread over in the New App Experience forum to discuss the performance problem I was seeing, which you can check out here, but after troubleshooting I’ve narrowed the problem down to the new app triggering a particular server behavior that the web app and the other older apps (i.e. Android TV/Fire TV) do not trigger.

What I am observing is that when opening certain problematic items, in the new app t can take five minutes or more before the detail page displays. During that time, one or more Plex Media Server threads on the server spin at 100+% CPU.

I’ve reproduced the issue by making direct HTTP GET requests and observed that the difference is that the new iOS app passes the parameter includeRelated=1 to the GET request to /library/metadata/ wheras the web app is not. I can reproduce the issue readily on problematic items by using the View XML option in the web app, which also passes includeRelated=1. If I change includeRelated to 0 or remove the parameter, the item details return instantly. WIth includeRelated they take 5+ minutes to come back.

I haven’t figured out the pattern of the items that seem to trigger this behavior, but I have observed that they all appear to be movies. I haven’t reprod this in my TV libraries. Items that trigger the behavior are consistent however. The same item will cause the server to spin at 100% CPU for five minutes surviving server restarts if includeRelated=1 is included in the request. Items that do not trigger the problem consistently do not trigger the problem.

I’ve tried to rule out database issues by optimizing the DB within Plex and also doing an offline VACUUM, ANALYZE, and REINDEX with Plex SQLite. The integrity check finds no database errors.

Verbose logging does not provide any clues. There are no log messages showing what the server thread is doing spnning the CPU in between the HTTP request and Complete line. If I turn on verbose logging, I only see a message like this immediately before the Complete:

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)

Any thoughts as to what would be causing this?

2

Update: The problematic items all appear to be in Collections. If I remove an item from a collection, subsequent calls to /library/metadata/ITEMID with includeRelated=1 return immediately.

I was also incorrect in stating that the web app does not show this problem. it does, but the web app does not appear to retrieve the related items just to display the basic detail page for the media, like the new app does. In the web app, what I observe for items in collections is that the basic media details page displays, but the “below the fold” related items just shows a spinner.. and it does spike my CPU usage as well.

Is there a known issue with Collections causing this problem? Anyone else seeing it?

3

I don’t have the exact same delay that you indicated in your other post (I think you mentioned waiting a long time for the metadata to show for some movies?), but I can definitely see the CPU spiking when selecting a title that is part of a Collection - I can see at least 1-2 threads on my server jumping up to 100%. Doesn’t happen for a title not in a collection.

4

Also seeing similar spikes when using the web app - sort of surprised I haven’t noticed that before. Seems odd to have CPU spikes for basic data retrieval.

I do a lot of work with MS SQL server and normally when I see CPU spikes like that it’s due to database perf issues (missing indexes, bad query plans, etc.)

5

Started looking into my own library to see what I see.
I haven’t dug into it nearly as much as you however I can confirm the same / similar behavior.
Anything with collections seems to drag for an extended period. Even in the older apps (plex.tv, windows app, and android app (not new experience)). Collections themselves load. However, when you got a title that has related content such as a collection it simply does not load. In the new app experience, it is extremely sluggish (using the beta app available on Android for this) The collection list itself loads but once you open a collection it spins for a long period. If you select a specific movie that is part of a collection the same thing happens. Without even looking at specific process use, I can see an average increase in CPU utilization during this time on my Unraid Container.

6

Are you using manual or smart collections, or does it matter? I’ve tried reproducing your issue using the native server package on an Intel-based Mac (PMS 1.41.6.9606) and using the Plex official Docker image running on Pop!_OS 22.04 in a VMware Fusion VM, and have been unable thus far.

I have my entire movie library in a smart collection in both environments (published to my home screen for easy one-tap access to my library). I’ve viewed the details (and XML info) for a random selection of about 30 or so movies without experiencing any type of meaningful delay (nor does my CPU utilization spike or ramp up to anywhere near 100%). I’ve done the same browsing the library and collection in the new Plex client (iOS) without issue.

I’ve also got a fair number of manual collections which I’ve tested as well; however, I’ve not seen delays in viewing those movies’ details either (again, no CPU shenanigans).

This is being tested on a Late 2012 Mac mini with a Core i7-3615QM w/16 GB RAM. The VMware Fusion VM is running on the same system concurrently (2 cores, 4 GB RAM). So it’s no powerhouse.

7

These are all standard collections, automatically created by library update.

I think @Lazarus_Long may be on to something with a sub-optimal database query. I have only had a little time to spend digging in the database, but there is no dedicated table to track collections, which would only be a few hundred rows large in my case. I suspect that the collections are being represented in the other metadata and tag tables which are proportional to the number of items across all libraries. While the library where I am seeing this is not large, I do have a large music library. .

It would be super useful to figure out what database queries are being run to see if there is a missing index. Is there any way to get this out of the server? Was a bit surprised that verbose logs don’t show it.

1 Like
8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.