I had PMS running for years on a debian vm inside proxmox. I moved the content to a new and bigger machine. debian inside pve, too.
The same content wich worked on the old one, causes the scan of the music library to hang at a certain directory,
The file Plex Media Scanner Matcher.log is flooded with multiple entries per second:
I could imagine that a file got corrupt while copying over… however this should not stop the scanner from doing its job.
edit: removed logs
I had it hung at another directory first where I could find a broken mp3 file with ffprobe. killing the scanner process made it go further and its “accepting” the first directory now (even with the broken file…). ffprobe on all files in the new directory doenst show any errors.
Especially the TONS of errors in the logs make me feel uncomfortable
First and foremost, your database is atrocious (fragmented).
I’d like to start by cleaning that up and working toward what’s holding up the scanner
You did turn off DEBUG logging. In this one case, it makes it easier to see the big items but we will need it back on.
May 25, 2024 17:37:52.685 [139694148471608] ERROR - [Req#45] Unknown metadata type: folder
May 25, 2024 17:37:52.688 [139694148471608] WARN - [Req#45] QueryParser: Invalid field 'contentDirectoryID' found, ignoring.
May 25, 2024 17:37:52.788 [139694163991352] WARN - [Req#96] SLOW QUERY: It took 350.000000 ms to retrieve 16 items.
May 25, 2024 17:37:52.835 [139694120401720] WARN - [Req#f3] SLOW QUERY: It took 700.000000 ms to retrieve 24 items.
May 25, 2024 17:37:53.020 [139694122560312] WARN - [Req#119/Req#11e] SLOW QUERY: It took 350.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.044 [139694134221624] WARN - [Req#11d/Req#122] SLOW QUERY: It took 230.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.046 [139694163991352] WARN - [Req#11b/Req#121] SLOW QUERY: It took 290.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.054 [139694183856952] WARN - [Req#93] SLOW QUERY: It took 1000.000000 ms to retrieve 24 items.
May 25, 2024 17:37:53.054 [139694140787512] WARN - [Req#11a/Req#120] SLOW QUERY: It took 260.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.062 [139694118292280] WARN - [Req#11c/Req#123] SLOW QUERY: It took 290.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.081 [139694138678072] WARN - [Req#11f/Req#125] SLOW QUERY: It took 210.000000 ms to retrieve 1 items.
May 25, 2024 17:37:53.091 [139694122560312] WARN - [Req#119/Req#11e] SLOW QUERY: It took 490.000000 ms to retrieve 96 items.
May 25, 2024 17:37:53.226 [139694148471608] WARN - [Req#45] SLOW QUERY: It took 770.000000 ms to retrieve 24 items.
May 25, 2024 17:37:53.261 [139694159772472] WARN - [Req#10e] SLOW QUERY: It took 480.000000 ms to retrieve 24 items.
May 25, 2024 17:37:53.268 [139694120401720] ERROR - [Req#124] Unknown metadata type: folder
May 25, 2024 17:37:53.270 [139694183856952] ERROR - [Req#12c] Unknown metadata type: folder
May 25, 2024 17:37:53.272 [139694183856952] WARN - [Req#12c] QueryParser: Invalid field 'contentD
I would like you to consider using my tool, which optimizes the Plex database in a way Plex can’t (because it’s running).
What you’re looking at doing is:
Download the script
run it with sudo ./DBRepair.sh stop auto start exit
(If PMS complains and terminates the script – it can in extreme cases –
then stop Plex manually before running the script again. It’s a timing issue with PMS)
Now start Plex again and see where we stand
– It should be a lot more responsive
– The logs won’t be littered with “SLOW QUERY” every few records.
– We can then turn DEBUG logging back on and figure out what’s causing the next problem.
Please read the documentation & extra instructions in the README.md
Okay, I didnt know the db can fragment… especially since this one is not very old. I mean, what can I do differently but adding content one after another.
However, I ran your utility:
root@plex:~/plexdbrepair/PlexDBRepair-1.06.02# ./DBRepair.sh stop auto start exit
Plex Media Server Database Repair Utility (Debian GNU/Linux 12 (bookworm))
Version v1.06.00
[2024-05-26 13.41.31] Stopping PMS.
[2024-05-26 13.41.33] Stopped PMS.
[2024-05-26 13.41.33] Automatic Check,Repair,Index started.
[2024-05-26 13.41.33]
[2024-05-26 13.41.33] Checking the PMS databases
[2024-05-26 13.41.57] Check complete. PMS main database is OK.
[2024-05-26 13.42.46] Check complete. PMS blobs database is OK.
[2024-05-26 13.42.46]
[2024-05-26 13.42.46] Exporting current databases using timestamp: 2024-05-26_13.41.33
[2024-05-26 13.42.46] Exporting Main DB
[2024-05-26 13.42.51] Exporting Blobs DB
[2024-05-26 13.43.36] Successfully exported the main and blobs databases. Proceeding to import into new databases.
[2024-05-26 13.43.36] Importing Main DB.
[2024-05-26 13.44.04] Importing Blobs DB.
[2024-05-26 13.44.21] Successfully imported databases.
[2024-05-26 13.44.21] Verifying databases integrity after importing.
[2024-05-26 13.44.24] Verification complete. PMS main database is OK.
[2024-05-26 13.44.25] Verification complete. PMS blobs database is OK.
[2024-05-26 13.44.25] Saving current databases with '-BACKUP-2024-05-26_13.41.33'
[2024-05-26 13.44.25] Making repaired databases active
[2024-05-26 13.44.25] Repair complete. Please check your library settings and contents for completeness.
[2024-05-26 13.44.25] Recommend: Scan Files and Refresh all metadata for each library section.
[2024-05-26 13.44.25]
[2024-05-26 13.44.25] Backing up of databases
[2024-05-26 13.44.25] Backup current databases with '-BACKUP-2024-05-26_13.44.25' timestamp.
[2024-05-26 13.44.27] Reindexing main database
[2024-05-26 13.44.40] Reindexing main database successful.
[2024-05-26 13.44.40] Reindexing blobs database
[2024-05-26 13.44.42] Reindexing blobs database successful.
[2024-05-26 13.44.42] Reindex complete.
[2024-05-26 13.44.42] Automatic Check, Repair/optimize, & Index successful.
[2024-05-26 13.44.42] Starting PMS.
[2024-05-26 13.44.42] Started PMS
I started the scan right after the restart by your script and it hangs at the same folder.
Here the Logs with debug logging enabled:
edit: removed logs
Media Scanner Matcher.log is still flooded with the warnings.
It probably means they rolled off the end of the queue (PMS only keeps current + the last 5).
While this isn’t going to be fun to pin down – IF you know which directory it’s getting stuck in,
then you’re going to need to solve this by repetitive effort.
(Divide and conquer)
Move the whole directory out
Scan , empty trash, clean bundles
Move 1/2 the files back in
Scan files and observe the results.
Depending on the result, either
Move 1/2 of what remains back into the directory and try again
-or-
Move 1/2 of what’s there back out and try again
Repeat as necessary, selecting the appropriate “pile of files” to operate on until you find the bad one.
As for the DB fragmenting -
When you add media, there is some amount of fragmentation.
The DB is a single file
PMS is writing to multiple tables in that file.
The tables ‘fragment’ (records interwoven with others throughout the file)
This ultimately slows down the queries
It’s a fairly normal practice to optimize the DB from time to time.
I will perform the full optimization (what my tool does) whenever I do a full ‘load up’ of a server (caveat – I’m usually adding some 50.000 items to the DB and using HDD for storage. Your mileage may vary )
If you use my tool, some things you’ll notice in PMS
Searches are fast again
Library pages load fast again
Starting playback is fast again
( All my tool has done is fully export the data from the DB and then sequentially reloaded it with all the records of each table being stored contiguously again )
I just realized, I had the old server selected int the settings while enabling debug log and downloading the logs. Sorry.
I renamed the last directory shown and started the scan of the music library again. It hangs now one directory beneath. I can see those two directories last in the scanner logs.
I figured it out:
first of all, thanks to @ChuckPa for PMing me.
I started watching the progress circle in the plex webinterface app and then renaming the folder where it hangs. Comes out: the shown folder name has nothing to do with the actual file wich is the problem.
I then made use of the lsof command to see wich files are opened.
I grepped the lsof output by the mountpoint where the media is stored. And one single mp3 file was shown when the scan hangs.
lsof seemed more convenient to me than taking folder by folder out of the library or “halving” the library to pin it down. lsof | grep /media/openmediavault/
If I use the ffprobe command on it it gives me this output:
I created a complete new library with a folder containing only this one file and the error is reproducable.
The Plex Media Scanner Matcher.log is flooded again with the FFMPEG Warnings.
Without the file both libraries scan fine through all of the mess
The file plays fine in VLC and Window Media Player.
05 失意のパズー 久石讓 天空の城ラピュタ -Origina Soundtrack.mp3
Maybe its the filename?
Addition:
I checked again and renamed the file before to something uncritical. The flooding of the log file is gone. So there is definetely something wrong with how plex calls ffmpeg with the filename as parameter.
However, even with a “working” filename the scanner hangs and starts to consume ALL memory. (it takes up 96Gig of RAM on my machine and then crashes until the cronjob starts the scan again.).
Whatever the likely broken mp3 file does to the scanner is not good
Thank you for the lsof suggestion. That is the best way for those using linux who are skilled enough. Thank you for that. I’ll keep that in my arsenal to suggest to others.
This isn’t a problem with the filename.
Damaged files will play through the various media players because they ignore many attributes stored in the file. (minimalist approach)
ffmpeg / ffprobe, as you’ve found out, are more selective.
The best answer here is to replace / reprocess the file so as to repair whatever is wrong with it. (inaccurate bitrate messages are a good indication)
