plex still seems to work, so is this a real database corruption error, or some kind of broken query/code ?
Oct 16, 2018 21:15:14.281 [0x7fc587ffc700] ERROR - SQLITE3:0x10, 11, database corruption at line 80748 of [fc49f556e4]
Oct 16, 2018 21:15:14.281 [0x7fc587ffc700] ERROR - SQLITE3:0x10, 11, statement aborts at 10: [DELETE FROM gnsdk_queries WHERE “key” = ?;] database disk image is malformed
edit here some others
Oct 16, 2018 22:12:39.615 [0x7f2d7d3fc700] ERROR - SQLITE3:0x10, 13, statement aborts at 20: [INSERT OR REPLACE INTO gnsdk_queries ("key","value","timestamp") VALUES(?,?,?);] database or disk is full
Oct 16, 2018 22:12:39.616 [0x7f2d7d3fc700] ERROR - SQLITE3:0x10, 262, statement aborts at 25: [INSERT OR REPLACE INTO gnsdk_queries ("key","value","timestamp") VALUES(?,?,?);] database table is locked: gnsdk_queries
Oct 16, 2018 22:12:39.675 [0x7f2d7d3fc700] ERROR - SQLITE3:0x10, 13, statement aborts at 20: [INSERT OR REPLACE INTO gnsdk_queries ("key","value","timestamp") VALUES(?,?,?);] database or disk is full
Oct 16, 2018 22:12:39.676 [0x7f2d7d3fc700] ERROR - SQLITE3:0x10, 1, statement aborts at 1: [COMMIT;] cannot commit - no transaction is active
no joy, still same errors on @ Version 1.13.8.5395
It happens when I scan my music library (plex premium), I moved a bunch of files out of the plex main music folder (so I can do the plex dance, to get rid of tracks with dates in the future).
While in the linked thread, I manually cleared the bad data, I noticed these database errors (not sure if they were happening before or not).
So I restored to backup database (from before I modified the db), a few times now with different backups.
And yes, I stopped plex while modifying/copying/restoring.
My plex seems to function completely normally, aside from these errors spamming the log file during a music scan.
I have not yet let if finish scanning (since I started noticing the db errors), so I am going to let it sit all night/day until it does, then do empty trash/bundles/optimize and see what happens.
Personally, I don’t use Premium music. I’ve found that a manually curated music library (Music Brainz Picard) works better for me given my music tastes.
It probably i a corrupt DB after all but if you don’t have an old enough backup to go back to, there isn’t much point. It might be better in the longer run to just kill the library section so those records get erased and start again.
@ chuck, I definitely appreciate a manually curated library, but unless I am mistaken, premium music library is required for the auto mixes, lyrics, etc.
Also, neither music library offers much in the way of actual management or curation of music. No bulk edits, no playlists import/export, can’t even modify the auto-playlists.
But lack of basic music library management is a complaint for a different thread.
@ otto, thanks in my experience with sqlite3, when a database is corrupted, it is usually beyond repair.
That said I did perform a consistency check on one of the db’s I have been having problems with, and the consistency check is OK.
I will get around to checking the current db consistency and do the ol’ sql in and out once PMS gets around to finishing re-scanning my existing music library.
But I am pretty sure at this point, that I did not create this problem, and if the db is truly corrupted somehow, it is something plex did to itself.
This is not my experience with Plex databases. In the majority of cases they are save-able with the repair procedure.
And even if there is an unrepairable version, going back to one of the backups and repairing them usually restores the majority of data.
not that I have seen a ton, but most corrupted sqlite3 db’s I have seen have been the result of either bad hardware (ie disk or ram corruption) or power outage during disk write.
I had plenty of sqlite3 fun with mediamonkey and power outages etc.
I hope you are right, that the plex db is repairable (if indeed that is the issue), but to me that means it is not so much physically corrupted, but that plex allowed its database to get out of expected specification, and then chokes on its own resulting errors.
Basically, databases typically do not corrupt themselves, but simply do as instructed by whatever is manipulating them. Whether that was an outside force (hardware/powerout/external user manipulation/etc), or internal programming to the application controlling the db, is the question.
googling gnsdk queries seems to indicate this is part of the gracenote functionality.
I do appreciate both of your help and insight, thank you.
If you see only errors in connection with the gnsdk, then the corruption may be not in the main plex database but only in the gracenote database.
Which is rather easy to fix:
Restart Plex server. It will automatically recreate and rebuild these db files during the following hours.
During this time, Gracenote-related functionality may not be working as expected.
