Super Sonic analysis not working at all for me - caused by database corruption?

Server Version#: 1.24.0.4930
Player Version#: N/A

Plexinc Docker image on an Unraid 6.9.2 server. Intel i5-4690k CPU. Originally I ran PMS on a Terramaster NAS and migrated my system to Unraid in November 2020.

I enabled Sonic analysis on my music library on Friday morning, but after a few days of letting it run it doesn’t seem to have done anything. My library is pretty small - 785 albums - and the status shows that it still has 785 albums to process. I’ve looked through the logs and I can see that it attempts to start the analysis and shows 0 of 785 processed, but nothing after that.

There are also errors in the logs about database corruption, and I’m working on the assumption that this is the reason my Sonic analysis won’t run. I’ve been getting notifications about corruption for a few months and have tried to repair the database on numerous occasions, without success. When I run the integrity check command, it always returns ‘ok’ and until now I’ve never noticed any effects of the corruption at all outside of the notifications, so I just accepted it and moved on. I’ve been getting notifications that my backups haven’t been running as well, but when I check the directory on my server, the new backups are always there.

This is the error in my Plex Media Server.log:

Aug 17, 2021 04:12:16.976 [0x1498494e4b38] ERROR - SQLITE3:0x80000001, 11, database corruption at line 67162 of [1b256d97b5]
Aug 17, 2021 04:12:16.976 [0x1498494e4b38] ERROR - SQLITE3:0x80000001, 11, statement aborts at 10: [insert into blobs (linked_type, linked_id, blob_type, created_at) values (?, ?, ?, ?)] database disk image is malformed
Aug 17, 2021 04:12:16.976 [0x1498494e4b38] ERROR - Exception inside transaction (inside=1) (../Library/BlobDatabase.cpp:65): sqlite3_statement_backend::loadOne: database disk image is malformed
...
Aug 17, 2021 04:12:16.977 [0x1498494e4b38] ERROR - Butler: Uncaught exception running subtask ButlerTaskGenerateIntroMarkers: sqlite3_statement_backend::loadOne: database disk image is malformed

I guess [1b256d97b5] refers to a table, but I don’t know which one.

From the Deep Analysis logs, I could see more errors about a malformed database disk image, which always coincided with some kind of activity being carried out on my music library. Yesterday, I actually removed my music library and re-added it from scratch to see if that helped, but there was no change. I’ve tried the automatic and manual database repair methods from the documentation, but neither have cleared this issue.

So my questions here are:

  1. Am I right in thinking that this corruption is breaking my Sonic Analysis?
  2. Does ‘database disk image is malformed’ refer to specifically the database, or is there something wrong with the SSD that hosts it? Could I migrate to a different SSD and fix the problem?
  3. Do I have any hope of fixing that corruption, or would I be better off just rebuilding my Plex server and starting fresh? Obviously I’d rather avoid rebuilding, but I think migrating from my crappy NAS last year really didn’t help matters.

According to the error log, it is the “blob” database file which is corrupt, not the main database file.
i.e. perform the repair procedure, but use the file name com.plexapp.plugins.library.blobs.db

Sorry, I am not a Linux guy so cannot answer any question which relates to Linux and/or Docker.

Thank you, that was a good spot, I’d completely missed that.

I ran the integrity check against the blobs DB and it was definitely showing problems. Running the repair reported a success and a second integrity check came back clear, but after starting my server again, the logs are still showing the same corruption on the same line of the same table.

I’ve kicked off the Sonic analysis again, but I’m not optimistic that it’s going to work.

As expected, the analysis is still not progressing.

Does anyone have a suggestion for something I can try next, before I resort to rebuilding my server?

Do you have an unusually large album in your library, perhaps with hundreds of tracks inside?
If so, you might just have to wait and hope that your temp folder has enough free space.

Nope, it’s pretty much just all just ordinary albums. There’s a handful of live albums that come with audio liner notes and the biggest of those files is 592MB, but I think that would have been analysed after four days. Everything else is standard stuff.

Is that lossless or lossy compressed?
In other words: not the file size matters, but their play time.
Because all files are being converted to WAV for analysis.

That one huge audio liner note file is actually well over 4 hours long, but it’s just a 320kbps MP3 so I imagine it’s lossy.

In any case, I’ve gone ahead and created a duplicate Plex instance this morning, and am gradually setting it up the same as my original system. Sonic Analysis is definitely working on this duplicate instance, so I think it was probably the database corruption causing my problem.

It’s a bit of a pain having to re-do all my posters and collections and stuff, but at least I’m on a firmer footing with a more stable database from now on. Thanks for trying to help, but I think this is the only way forward.

What worked for me was (after backing up the “com.plexapp.plugins.library.blobs.db” of course) deleting the blobs DB entirely. (if it was screwed up, that probably explains why intro detection never worked for me). The server rebuilt it, and started scanning successfully. I’ll post back if there are any negative side effects.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.