Are you on the updated server for today?
@derico said:
I had the same issue, until I enabled the Use embedded tags option for my music library. It looked like Plex took one more pass through all the music files and since then it seems back to normal - no more constant scanning and new items in any library are detected and matched almost instantly. Have not checked many music items in detail, but Iād say it is worth a try.
I already have āuse embedded tagsā option enabled and it still happens regardless.
Additionally, the bug is quite painful for Movies & TV shows as well. Thereās no āuse embedded tagsā option for those libraries, even if it were to be beneficial.
I am still on 1.12.1.4885 and it seems to be working well for the past two days.
The option only exists for music, but since it is not constantly scanning anymore, matching TV and movies is fine - at least for me, for now. The server might behave differently on other platforms.
@derico said:
I am still on 1.12.1.4885 and it seems to be working well for the past two days.
The option only exists for music, but since it is not constantly scanning anymore, matching TV and movies is fine - at least for me, for now. The server might behave differently on other platforms.
Ah, I understand now. Yes, this is true for me as well, until you add new music, or even open a folder, or have an automatic scan occur. The cycle will happen again.
I am gonna try the updated server version tonight and see.
I might have spoken too soon. Plex appears to be scanning music non-stop for the past hours again. Sorry.
@derico said:
I might have spoken too soon. Plex appears to be scanning music non-stop for the past hours again. Sorry.
Are you on the new server version? I didnāt do the update last night. Just wondering.
Not yet, will update later today.
Based on this thread and the previous release notes I believe this bug is due to a (Library) fix. See here: https://forums.plex.tv/discussion/comment/1643317/#Comment_1643317
As of the most recent release notes thereās been no update to the library or scanner: https://forums.plex.tv/discussion/comment/1645660/#Comment_1645660
Edit: earlier in the thread it was stated an issue has been raised. Until we see a specific release mentioned here or in the notes Iām assuming itās not fixed.
@sa2000 Do you have any updates here?
@āKyle Verryā - cāmon - he raised the issue, now weāll know when we see it in release notes. This is the way of Plex. 
The bug may be fixed after they release a client for the Mars rover first.
@JamminR said:
@āKyle Verryā - cāmon - he raised the issue, now weāll know when we see it in release notes. This is the way of Plex.
The bug may be fixed after they release a client for the Mars rover first.
True dat, right?! Though, I suppose the cause for apparent impatience is that I fear they do not THINK this is a bugā¦
Hopefully it is being treated as a bug. 
I donāt know if an issue is evaluated and then dismissed or turned into a tracking bug/defect.
I just got some good news, and I donāt think I am at liberty to say how/where, but it seems this is identified, and could be fixed within a very short amount of time. Yay!
I am just happy they confirmed it is a bug and not a feature. Whew.
The best news! Thank you Plex devs! 
I just got an update from 1.12.1.4885 to 1.12.2.4929, and Iām happy to report that (so far as I can tell) the endless scanning of music libraries is killed. Are you all seeing the same?
Iāve been lurking watching the progress in this thread but I just installed in 1.12.2.4929 and it fixed the issue (feature?) for me. It was getting beyond frustrating so Iām glad that Plex addressed it quickly!
It might only look like itās fixed for you both because the server is restarted implicitly after the update.
I am on 1.12.2.4929 as well and the scanning continued soon after with the next periodic library update.
As @āKyle Verryā mentioned, Plex confirmed it is a bug and would be fixed āshortlyā.
Yeah, I spoke too soon. As soon as I add any media to a library, Plex sees the change and scans the new item (as it should), then begins a scan of that entire library, again. One difference Iām seeing is that in 1.12.1.4885 when I would cancel the scan of one library Plex would then move onto the next library and begin scanning it, until I had cancelled scanning on all libraries. In version 1.12.2.4929, just now when I cancelled the scan of one library it didnāt move on to another library. I suppose thatās an improvement but the underlying issue still seems to be there.
I upgraded to 1.12.2.4929 just to verify and the behavior is still there. I donāt mind the scanning, itās the exorbitant amount of time spent āmatchingā that makes the server unusable. As already discussed though, this is identified and will be fixed.
Letās wait until itās called out in the release notes. Probably the best way to do it.
I have also experienced this issue. I agree with wdtvswns. The scanning seems to go lightning quick. However, the matching takes forever, and pegs the CPU utilization on every cycle. I have disabled periodically check libraries and that seems to solve it other than not having updated libraries (a pain, but simple to manually update). I cannot attest to exactly WHAT is causing the problem. It could be trying to match, getting time-outs, repetitively trying to match, until it gives up. I see the notification metadata for xxxx complete. However, on the next scan, it tries to download the same metadata, eventually says complete again. The entire cycle pegs my CPU for ~45 minutes to an hour. I also have use embedded tags enabled. My music library is a PlexPass premium music library.
I tried the 4929 update, same results.
On one of my servers I downgraded to 1.12.0.4829 with periodically refresh libraries every 6 hours enabled. The libraries show updates, there is no periodic every 6 hour CPU pegging.
My libraries are all on a NAS mounted with cifs, so it is my understanding that monitoring folder changes is ineffective (also my experience evidenced by libraries with changes not getting updated).
Hereās hoping a quick update resolves the issue.
