Trying to find the cause, why PMS is corrupting its own database after a while

Server Version#: Version 1.18.4.2171
Player Version#: Version 1.4.1.940-574c2fa7

Coming from this Thread and following the steps, @ChuckPa proposed:

As The Root Music Folder of the NAS is very very large, I will do something like symlinking more and more main-folders over the time and not all at once, as I did the last times. Maybe we can find out, when the DB gets corrupted with diffs from the DB backups… who knows…

I am posting here too.

Don’t use symlinks.

If you are, this may be the root cause of your problem.

Create additional shares if needed…
-or-
Create sub folders and then add each sub folder individually

whatever you do, don’t use symlinks. Synology does not do well with symbolic links.

I’ll need to think about a new concept with a new shared folder then, which I’ll use for this “project”… That’ll take some time, because other services/programs use that shared folder too, so I cannot change its contents easily…

Not using Symlinks atm, it was just an idea becaue I cannot move/copy content easily.

I understand. NAS storage architecture changes are never easy.

With Plex, the biggest thing to keep in your mind during design is the kernel’s Notify service. I-node notification is used heavily in Plex. Media changes are detected this way. The transcoder uses it for certain codecs.

You can see my current folder structure here:

inotify worked very well until now, but lately I had set up Plex to not scan my library automaticly or when changes occured (but I noticed, that Plex did it anyways) because it was not needed to be up to date.

Curating music is a) a labor of love and b) a P.I.T.A :wink:

1 Like

I have a pretty plain and simple Idea:

I will put a .plexignore in each main-folder (a-z), so Plex can or will not scan anything inside those folders.

Given the above quoted folder-structure

\\server\folder\music\a\artistnames\artistsalbums\files
\\server\folder\music\a\variousartists albums\files

\\server\folder\music\z\artistnames\artistsalbums\files
\\server\folder\music\z\variousartists albums\files

it will look like this:

\\server\folder\music\a\
\\server\folder\music\b\.plexignore
\\server\folder\music\c\.plexignore

\\server\folder\music\z\.plexignore

New Plex Library will be created at
\\server\folder\music\

So on the first run, PMS will only scan
\\server\folder\music\a\

After that run is finished, I remove
\\server\folder\music\b\.plexignore

and start a rescan of the library, so Plex will only scan
\\server\folder\music\a\
\\server\folder\music\b\

and so on, until
\\server\folder\music\z\
is reached (or we discover that error/bug/crucial file/folder).

Do you think, this is a valid idea/way ?

I can go one better and avoid the fuss of a .plexignore

  1. Create the library section
  2. Only add \\server\folder\a
  3. When complete, add the next letter (\\server\folder\b)
  4. Repeat process until all media added.

Now, you’ve added it under your control.

There is no limit to the number of folders which can be included in a section.

1 Like

Ok, PMS is indexing right now, I’ve added A,B,C,D and it surely will take until tomorrow, when I add the next ones.

Meanwhile, I have a question, regarding the procedure, we’re doing:

How can we find the culprit/error/bug that way?

Are you guessing/hoping the error (corrupt db) will not show up again, when files are added slowly and in single steps? Or what is the path we’re following? I’m trying to learn.

There are a couple ways the DB could have gone sour.

  1. If the problem is quantity or size (list length / memory allocation maximum) being exceeded. This will show itself when “X” items have been loaded regardless how they are loaded.

  2. If the issue is protracted, uninterrupted, additions to the database, adding one block at a time will sidestep the issue.

There is still the issue of database integrity during this. I failed to mention “Optimize Database” as a step to perform between adding each section. While it should not impact the results, it will impact (improve) the performance. I am reticent to perform this step not knowing the total number of items to be added to the table.

Thanks for the reply!

The Problem did came back:
You see the artist Alain Goraguer with about 638 albums.


Those are, VA albums, no albums by Alain Goraguer.

Explorer shows 6 folders aka 6 albums:

Various artists are double (and I guess, other artists have doublettes too, because Plex doubled a lot of artists the previous attempts when indexing the music)

This is the Database directory:

Btw: speaking of optimizing the DB, I did a count of my root music folder: 739434 files and 92078 folders.

Optimizing took 1-2 hours and I tried it a lot the last months, but it never did something helpful, like speeding up access to the db or magicially fix things (which I did not expect), it was just a try to see what happens after I clicked the button.
The only thing which happened: Plex settings were not reachable for 1-2 hours of optimizing, I had opened another ticked on that subject, but no solution so far…)

What next?

DB size is small, so are the logs. should I send them?

Before proceeding further, allow me to check with Engineering.
The size of the WAL (pending transaction) file is alarming to me.
It should be near zero.

Given the gross misclassification of the albums, there must be something else going on.

my WAL file is almost always increasing to the same size (or there about) as the db file, until pms is restarted, at which point the WAL will shrink, then expand over time, until the next restart.

That’s how it should be. When PMS is stopped, all pending transactions in the WAL file should be committed as the SQLite3 session ends.

I’m confused, you said the WAL should be near zero.

I am stating that my WAL is never near zero except at PMS restart.

My DB is in excess of 1 GB, as well as the WAL file.

This has been the behavior for as long as I can remember.

if this is not normal (per your WAL should be near zero), then I am simply saying that the behavior is not only with FlexiPlexi system.

Correct, at PMS start, the WAL should be at or near zero.

From the SQLite3 documentation:

  1. Write-Ahead Log ( WAL ) Files . A write-ahead log or WAL file is used in place of a rollback journal when SQLite is operating in WAL mode. As with the rollback journal, the purpose of the WAL file is to implement atomic commit and rollback.

and

  1. The WAL file is part of the persistent state of the database and should be kept with the database if the database is copied or moved. If a database file is separated from its WAL file , then transactions that were previously committed to the database might be lost, or the database file might become corrupted.

While PMS is running, the WAL file grows to accept the in-process changes.
When PMS shuts down, SQLite3 commits these to the DB.

1 Like

Ok, I get that, and the sql3 doc info.

What I don’t get, is this…

Is the screenshot above, showing 219 MB WAL, with PMS running or stopped ?

Ah, well that is not mine, and it does not appear to be stated if that is running or not.

I assumed running.

(yes I know what assume means :wink: )