Strange. I don’t see the playback attempt. But I do see a user that you share your server with requesting all the details from all of your libraries. You have a lot of content so it’s taking PMS a while to generate this info and pass it back to that user. This could be the spike you see.
Digging into this a little more I found that the for “problem” movies the “View XML” link under “Get Info” will not load. I assume if that can’t be loaded then playback will never even try to start. It also seems that just trying to view that XML causes the CPU load on the server side.
this sounded like a similar issue->
And I had the same experience, if I update the includeRelated query param to =0 then the xml loads instantly (no CPU death spiral)
I’ll also note that disabling includeRelated for “good” media (media that doesn’t cause a death spiral) makes the metadata responses much faster (as just a few ms) where as it can take 2-10secs when that flag is enabled. This is similar to the playback delay I notice when starting playback. I actually haven’t checked if playback uses this query param flag to request metadata before playback… but seems like includeRelated would not be needed for regular playback…
Yes, this does seem to be a similar issue to the one I’m having. Playback is not required to get a server to go unresponsive.
I’ve also disabled all HW transcoding, and even transcoding alltogether and the issue persists. (Even though these files should direct play rather easily on my Shield Pro or Windows client.
I’ve had some small success with my script that runs through each item and refreshes each item… but even that will sometimes crash the server with a timout=30.
1.31.0.6654 also seems to be affected.
Yeah… This has been my experience as well. You wouldn’t think Plex would need to pull this metadata before playing an item, but it does. For what reason? I have no idea. It makes sense to refresh the metadata when someone loads the info page, but not when someone is trying to play the file.
It’s been a real PITA, if you get a real “persistent” person who wants to play a specific file they can repeatedly crash your server for hours and there’s not much to go by in the logs because Plex doesn’t try and actually initiate playback until after the query finishes. (It never does)
This is exactly what has happened to me and why I started this thread. I’ve seen my husband do it, he goes to play a movie, it doesn’t play, tries again, it doesn’t play. Tries another time and bam server is dead, CPU is at MAX, the last lines of the console log show “slow queries” and the whole thing goes down for 10 minutes or I restart the server.
I suppose we won’t get a response from a Plex rep until Tuesday. Pure speculation I would guess its some sqlite query that isn’t presented in the logs and based on the query params for the metadata request it just spins (high CPU). AFAIK I don’t have a database issue; I’ve run the “ChuckPa” PlexDBRepair from github and it doesn’t report any issues.
For an immediate fix it seems like the playback metadata request could be simplified to not cause the CPU spike and non-reponse (as well as faster playback startup times in general) Long term the query causing the high CPU (non-response) needs be investigated/resolved.
If I can be any help running metadata requests or db queries directly, just let me know.
I’ve also ran numerous DB export/import/reindex with my own scripts and ChuckPA’s and nothing helps. The only thing that helps is sometimes a refresh/analyze will correct it but more often than not completely removing the item from the library and rescanning it.
Currently I’m testing the legacy movie agent, and while it’s super slow to pull metadata the “View XML” is nearly instant now. With or without includeRelated=1. Not a solution for obvious reasons, but if it stops my server from crashing I’ll live with it for now.
Does refreshing the movie allow this to work?
Yes, but I have seen instances where attempting to refresh metadata for the item also crashes the server.
And even if the metadata does refresh correctly it breaks again in a week or so.
There is a scheduled task to refresh the metadata periodically. It’s possible there is something being picked up wrong causing this breakage. You can turn this off so it won’t break on it’s own.
Next time you see a crash, please grab the PMS logs right away and send them to me. This may all be due to 1 piece of bad data in the database.
Yeah, I’ve tried keeping that disabled as I thought it would help but it still happens. I’ve been troubleshooting this for well over a month and have tried nearly every version of PMS going back to 1.29 which used to be perfect.
As far as logs go the only log entry is the request query for the metadata with includeRelated=1, and then no response. I generally have debug logging enabled but have also checked with verbose.
I don’t currently have any broken items because I just remade the library, but will pull logs for you when it happens again.
MovieFan.Plex:
Does refreshing the movie allow this to work?
When you say refresh, do you mean Refresh Metadata No, it doesn’t make a difference. Only thing I’ve found to work is removing the movie, refreshing the library (to delete it), then re-adding the movie and refreshing the library again. Even that isn’t 100% effective though.
EDIT- Actually I just tried it again and it did work on anther movie (Refresh Metadata); So perhaps it does work, but I guess at the same rate as removing and re-adding, so not always…
I have similar symptoms I can’t get CPU data though since the whole thing locks up. I have found certain clients seem to be more likely to cause it (Samsung 2018) tv.
While mashing refresh metadata does seem to work most of the time, its hard to identify which entires are causing issues until you attempt to play them (or test manually via view xml metadata) Most of the time though its a remote user is continually trying to play something and bringing down the server over and over with no indication in the logs as to whats happening. Is there any sql query to run to be able to see which entries are in this “bad” state? For me most of the time its “longer” or “larger” files (longer files tend to be larger) If you need me to run anything on my side to confirm, test, etc just let me know.
If it’s corrupted data, Repair a Corrupt Database | Plex Support, has info on how to check. If it’s bad data, these are not detected. You just have to look manually. The next time you run into this, you can try checking the database for that video. Although if it is due to “includeRelated”, then it could be bad data on the related video and you wouldn’t know which one.
I’ve checked manually as well as using “ChuckPa” PlexDBRepair tool and didn’t find any db corruption. How could it be another entry causing the issue when using includeRelated if refreshing the metadata resolves the issue? Is there a way to see the query that is being run so I can run it manually to try and see what might be happening?
perhaps the best course of action would be viewing an entry when its "bad’ and then again after its working (refresh metadata) and check the diff… what tables should I be looking at other than metadata_items?
updated edit; besides timestamps changing after refreshing, the only thing I saw different in the metadata_items table for my “bad” entry was in the extra_data field. My “bad” entry has this → cloudAssetRefreshedAt=1677255425 and my refreshed working metadata did not have that in the extra_data string ¯\_(ツ)_/¯
Ok, that looks fine. It may be as I feared and it’s not the movie that is the issue but the related movie data. When Plex scans a movie, it identifies what other movies are related to it. You can see this in the good xml. There should be a “Related” section at the bottom. My guess is that it’s one of these “Related” movies that may have the bad data, so when it tries to use it to generate this section, it fails. That’s why “includeRelated=0” makes it works, since it tells PMS to net generate this section.
If you can find a “bad” movie and let me know what it is, I can find out what the "Related movies could be and you can check if you have it and the data is bad.
but why would it work after refreshing metadata on the original “bad” movie (even when with includeRelated=1)? would the related movies list actually change from refreshing the metadata?
The movie was “Star Wars”
Want to chime in that I’m experiencing the same issue, and Star Wars was also the culprit for me last night. The fact that it’s the same movie for unrelated users in separate databases tells me it has something to do with the info Plex is pulling/generating for the movies.
Also worth noting, possibly, is that I have quite a few versions of Star Wars (fan edits, etc.), and the user tried playing 6 different versions of Episode IV. I never saw the playback start on my dashboard, just the CPU spiking to 90%+. It wasn’t until they messaged me that the movie wouldn’t play that I had any idea what was going on. I was also not able to get any version of the movie to play locally, and was not yet aware of this reported issue.
Restarting my server and refreshing the movie’s metadata worked. So it seems wholly related to the metadata or some other form of data associated with the movie title itself, since every version of said movie encounters/triggers the same issue, and the same movie is triggering this issue on different servers/databases.
edit: Tried looking for other movies that cause similar issues, sorted by bitrate and checked out my highest bitrate movies by playing them in a web browser on a local machine. Most 90-110 Mbps bitrate files played fine with an expected server load (less than 10%, dropping down to close to 0%, despite transcoding from 4K HDR10/DoVi down to 1080p). Ghost in the Shell (a 100 Mbps bitrate file), however, drove my CPU up above 40%. Even just looking at the movie in the library spiked it above 10%, and it maintained a 30-45% CPU load as it played. My server has a Ryzen 9 3900X 12-core CPU running at 3.8 GHz, just for reference, There’s no reason any single movie should spike it this high. I let the movie run for about 10 minutes, and it took around 45-60 seconds after stopping playback for the CPU to drop back to 0%. I refreshed metadata and played it again - same initial CPU spike and average server load. I then analyzed the file and played it again - same spike. Similar movies with higher bitrates like my 16mm digital transfer of Super Mario Brothers: Great Mission to Rescue Princess Peach that’s 123.5 Mbps bitrate, and my 4K BluRay transfers of The Thing and Flatliners that are the same codecs and on the same drive as Ghost in the Shell, and are also around 100 Mbps bitrate, play without issue, and the CPU doesn’t go above 7% before settling to near 0% as it should. Seems related but idk for sure. Wanted to post the info just in case.
