I think the primary issue is finding out why the “View XML” makes plex go unresponsive when “includeRelated=1” is included on an item that is “broken”
It seems like this particular query is stopping anything else from happening until it’s completed. And in the case of these specific items where the XML doesn’t load Plex go unresponsive until it’s been forcibly stopped.
In the DEBUG logs you can see the request come through for the items metadata, and then there is no response for X minutes. WebUI and clients all stop working while that’s happening
@ChuckPa I forgot I had a server with only my 4K content still using the new agent. I’ve found an item that causes the server to go unresponsive when loading the XML with “includeRelated=1”
I’m happy to invite you to this server or give you a copy of the database. Whatever you need
It seems at least somewhat related to movies with a significant amount of related content. Multiple users here have had the issue show itself on the same movies (Star Wars and Empire Strikes Back) despite being on completely unrelated databases with different builds and installation types. It may be good to have all the Star Wars movies in the database, as my assumption is that there’s something in that “related content” query that causes the hangs. Worth keeping in mind, anyway.
For clarity, when we are saying “includeRelated” This it is not a UI option for plex. It is a url query param used when calling the api for metadata. ex->
^ in this url request you can see the includeRelated=1 query param. If this is removed (or set to =0) then the response for the metadata request will be much faster. You can replicate the above api call by going to a movie in your library, then choosing More → Get Info → View XML This will trigger an api call for the metadata with includeRelated=1 query param.
Now for some reason some newly added media when using the new plex movie agent will be in a state where when this query param is used it will spike the CPU for several minutes while processing the request. If multiple api requests are made for the same item then it will compound the issue and consume all resources on the machine until the server is unresponsive.
Now the real world issue is that this metadata request is made (with the includeRelated=1 query param) anytime playback is initiated from a user. So simply trying to play the content will trigger this issue. If a user is persistent and attempts playback multiple times, then the metadata api request is made multiple times and it puts the server in an unresponsive state.
The “quick fix” would just be to remove the includeRelated=1 option for metadata requests on playback. It wouldn’t solve the real issue, but it would be a better experience for users until the issue can be found and corrected. It seems like an un-needed query param option just for playback to start.
I can only assume the player is waiting for some value in the response before it starts playback, otherwise why even call it at all… but I’m not a plex dev
agreed, 2 part issue, slow response in any gui on pulling related titles under certain conditions. something metadata related likely but we haven’t found the exact hubkey/tag/tagging/agent culprit. I get the same ‘delay’ on loading a movie in windows client, ios, and web. the main movie loads and a few seconds 7-15 the remaining data.
but the biggr issue is whatever circumstance causes said delay, it also manifests in a playback delay when starting a movie.
this playback delay can be simulated and/or validated via More → Get Info → View XML as @jseeley stated.
A browse delay is tolerable(ish) but the playback delay seems un-needed.
I did manage to get to more like a 7 second delay by switching back to the TMDB legacy agent. I’ve scanned metadata, unlocked any locked fields, optimized etc.
Last night I noticed that the slow loads don’t seem to cache. Even if slow, if it cached wouldn’t it be faster the remaining tiimes? Every time I revisit a film the extras pop up quick as does the movie details but the related items are still blank. Web client not the best for testing with F5 but on IOS it is repeatable.
I have deleted Caches folder in Plug-jn Support to let plex recreate it.
Maybe permissions are fubar somewhere in one of our /config folders?
Yes, it’s still unclear what the includeRelated=1 query param actually does. One would think if it was just a change in the db query that subsequent hits would be cached and it would be faster. So perhaps it accessing something on the file system, or oven an api call to somewhere else. The fact that it spikes CPU so high is what makes me think it’s a database call, but many things could spike cpu as well.
I my try migrating from binhex-plexpass to lsio’s docker this weekend and see if it is happier.
I keep coming back to collections/genres and wondering if it was stuff I did with PMM in early phases. The reason I went down the path of pragma page_size 4096 and cache_size (before the cache size was editable) was that my categories tab never finished resolving. It’d spin and spin until I grew the cache etc.
The other thing about collections and genres and smart collections is the
hub/hubkey stuff.
context=preplay%Ahub.movie.similar movies .similar etc as a hub
Maybe the updates back here https://www.plex.tv/blog/hubba-bubba-introducing-custom-collections-and-hubs/ are involved.
Extras loa right off, but not related items. I keep hoping @ChuckPa or @anon18523487 can spot something in one of our databases. A missing index, missing trigger, bad view, metadata relationship etc.
any idea where to poke in database for the similar relationships?
There are 3 entries in the related section
Hub hubKey=“/library/metadata/149042” key=“/library/metadata/2705/similar” title=“Related Movies” type=“movie” hubIdentifier=“movie.similar” context=“hub.movie.similar” size=“1” more=“1” style=“shelf”>
I’m guessing it is the similar entry causing the issues.
I suppose I could muster through a sql query for the actor and director and see if they are slow.
I have a copy of my database tar’d and ready to share with @ChuckPa if you’d like it, as well as a few titles that are known to cause the server to lockup.
I’m getting close to nuking my db. I deleted tags, chapter thumbnails, been trying to clear whatever I can. I’ve had to do 2 db restores and a whole appdata restore since all my troubleshooting seems to have killed my docker.db
Any hint of progress on what movies.similar hubkey metadata relationship may be broken? I’m down to 10 or so seconds delay with the tmdb agent.
I’ve started reading up on migrating watch status and how to keep as much of my setup as possible while starting anew.
I also started my jellyfin/emby testing.
I don’t want to regenerate thumbnails for everything and fix posters and titles again. But my uptime and stability is seriously compromised and the fun level is down.
Hello! I started this thread and finally had time to find another movie with this issue.
I got Ant-Man 720p x265 from PSARIPs. It’s something people can find easily and test against. It does not always play and triggers this issue for me. One attempt to play last night almost crashed my 16 core AMD Win10 OS server. I have an NVIDIA 3060 RTX which I leverage for Hardware transcoding since all my users have friggen Roku sticks which struggle to play most formats and force transcoding on my side.
I’ve enabled debug logs while no one else is using my plex and attempted to play the movie. First time in Brave (aka chrome) failed, one time from my iPad worked, and then once again from my browser failed endlessly. Slowly CPU spiked higher and higher until PLEX was unusable. I managed to get the DEBUG logs out of it and restarted the server to clear the CPU spike.
Received.
)