Hey @TeknoJunky! 
DM me for an invite into Slack, I think we might be able to diagnose this more quickly in real-time. In the meantime, an lsof of the “hung” process might be useful.
3 Likes
After the work we did last night, I found something else this morning.
- it is not necessarily the number of files in a folder … it appears to be the number of files in an ALBUM.
unknowingly, one of my sxsw albums was split up between different folders in my library file system.
neither folder was over 1000, but together they made an album that was over 1000.
and guess what, plex was hung this morning with those files spread out over 2 folders.
so there is another data point, I don’t know if that changes what was determined last night, but wanted to pass it on.
test build seems to be flying through problem free at this point, so good news ahead for anyone else affected.
You might be on to something. I’m running latest Plex Pass beta on a Windows 10 machine. There’s one folder I have with Music Boxsets which struggles tremendously. The most files I have in any folder is 489.
CPU is 50-60% on all 8 cores, so not 100%. I keep getting a bunch of these in my logs:
Oct 11, 2019 12:29:37.207 [11552] WARN - SLOW QUERY: It took 218.750000 ms to retrieve 50 items.
Oct 11, 2019 12:29:37.271 [11552] WARN - SLOW QUERY: It took 328.125000 ms to retrieve 50 items.
Oct 11, 2019 12:29:37.319 [11552] WARN - SLOW QUERY: It took 234.375000 ms to retrieve 50 items.
Oct 11, 2019 12:29:42.345 [11552] WARN - SLOW QUERY: It took 32609.375000 ms to retrieve 50 items.
Oct 11, 2019 12:29:48.013 [11284] WARN - Held transaction for too long (…\Library\MetadataItem.cpp:6405): 0.250000 seconds
Oct 11, 2019 12:29:48.026 [11284] WARN - Held transaction for too long (…\Library\MetadataItem.cpp:6405): 0.125000 seconds
Oct 11, 2019 12:29:48.104 [11284] WARN - Held transaction for too long (…\Library\MetadataItem.cpp:6405): 0.562500 seconds
Oct 11, 2019 12:29:48.122 [11284] WARN - Held transaction for too long (…\Library\MetadataItem.cpp:1037): 0.125000 seconds
Oct 11, 2019 12:29:48.140 [11284] WARN - Held transaction for too long (…\Library\MetadataItem.cpp:3516): 1.531250 seconds
Oct 11, 2019 12:29:48.244 [8916] WARN - Held transaction for too long (…\Statistics\StatisticsManager.cpp:248): 0.375000 seconds
So yeah, I think it’s the scanner that causes problems
that looks like the hard drive your plex db is on, isn’t keeping up with the updates that plex is trying make with the database.
I have a few folders over 500, but its only the ones around 1000-1200 that kept crashing.
its not exactly the scanner, its right after, when plex starts to match the files it just scanned. That takes quite a bit of cpu when it happens, but it is also bouncing around a lot, not just pegged at 100%.
after it finishes matching that set of files/album, then it starts downloading the various metadata and the cpu usages drop to more reasonable level.
after restoring all files/folders to their original place in my music library, the test build I was provided was able to finish rescanning everything with no further apparent issues and now I appear back to normal operation.
thanks plex team!
Aha, then it must be something else. Before the 1.18.0.xxxx updates, Plex didn’t have this issue. It goes on like this for 12+ hours (I’ve force quit Plex after that), and while that is happening web interface is not coming up, even on the same machine I have the server installed. A workaround for me was to install the 1.17.0.1841 version again.
2 Likes
I believe it was 1.18 that released the new metadata system, so 1.17 would not have this issue because only 1.18+ is trying to update your music library/metadata.
I’m having the same/similar problem with 1.18.0.1944 on Fedora 29.
yes, it keeps seemingly repeatedly over and over, but it will eventually stop.
my 220k track library took about a day and half to refresh all and was doing the same thing (looked like it was rescanning a lot). but eventually slowed down and started rescanning in smaller spurts.
I would recommend disabling - settings > library > rescan library periodically), this is what seems to be triggering the music library rescan. Or if you manually trigger a full library scan it will rescan library.
In order to stop the scan, you must cancel it at the server level, not the music library level.
settings > manage > libraries > cancel scan at the top right
see green arrow
I had to restart for another reason, and since then i only get the music scan during a full library scan (after disabling periodic scans).
yes this sucks.
no you can’t stop it, but you can avoid most of it
yes it blocks other library scans while scanning music
yes you can cancel it
yes you must rescan movies/tv separately unless you want the music rescanned
finally if you really think your entire library is matched, then go to your music library and it like below
well there currently does not seem any way to completely disable the new music scanner.
so the only thing you can do is work around it until they either allow it to be disabled entirely and/or make it smarter about rescanning the same things over and over.
or you can just let it finish, it will do so eventually (until the next rescan)
fyi: logs from a rare moment during the perma-scan when the app actually responded.
Plex Media Server Logs_2019-10-14_20-13-05.zip (12.1 MB)
To my knowledge, I do not have folders with more than ~200 files in the library. However, I do have a lot of obscure niche music… 250k files in 35.5k folders.
Currently updating to 1.18.0.1944… hope that helps
that is a lot of tracks, but unless your htop looks like screenshots in the first post, you are probably just seeing a lot of the cpu from the acousticid generation and matching.
the matching seems to use the most cpu, while the scanning and metadata download hit the disk io.
scan acoustic id > tries to match album > downloads metadata
repeats adnauseum.
pms 1.18.1.1966 appears to have resolved the music scanning hangs that I was experience.
hope it works just as well for others.
1 Like
It may be coincidence, but I just finished ripping and add this to my Music Library:
All told, there are over 1300 tracks contained in this 85 disc set. Needless to say, I am experiencing high CPU usage during scanning and crashing, but I am using Mac server. I did report this 9 days ago in this thread.
https://forums.plex.tv/t/plex-fowling-up-metadata-and-high-cpu-when-scanning/473048
Mac - Version 1.18.1.1973 is still experiencing high CPU and crashes. Maybe I will remove this box set and see how it holds up after that.
I have the same issue, Music scanner hangs on certain folders and will not restart. High cpu usage and crashing. Had to rollback to 1.17.0.1841. First time a problem has forced me to rollback server version.
Fyi : library was set to use ID3 tags for info
I have to do the same, nothing was working with Plex using 100% CPU.
I’m having the same issue. Plex is stuck at 100% since I updated to 1.18 for days.
Running 1.18.1.1973 on QNAP QTS.
UPDATE: Reverting to 1.17.0.1841 resolves the CPU issue. Something is clearly not right in 1.18…
Chrome: Plex Management interface
Following many library refreshes (scans), I observed at the end of each scan itself the CPU was going up and down for a while. Then I decided to close the browser where the Plex web management interface is running since i already observed major issues with Edge in the past. This stopped the high CPU usage, and the management interface become again available quickly.
Then, I initiated another library scan, and then I close the browser right after that, and the scan took the time as previous Plex releases (prior 1.18). When the CPU came back to low utilization), then I launched again the management interface with Chrome and it was working well (smooth).
Workaround : Initiate the library scan with your browser, then close it. Keep close until the scan is not completed, I was able to use mobile devices such as Ipad without issues while the library scan was running
Based on this observation, i think the issue is mainly related to the update in real time of the Plex management interface while the library scan is running
I have to say I’m still seeing this when I test 1.18.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
