mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: SQLITE_CORRUPT error on upgrade from 2.16.2 to any 2.17.x version #2374
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#2374
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @biuklija on GitHub (Nov 24, 2024).
What happened?
On upgrade to from 2.16.2, any newer version, the image crashes and reports corrupt database. Reverting back to 1.16.2 the same database works fine.
Migration failed: MigrationError: Migration v2.17.0-uuid-replacement.js (up) failed: Original error: SQLITE_CORRUPT: database disk image is malformedWhat did you expect to happen?
Image should perform the database upgrade and start.
Steps to reproduce the issue
Audiobookshelf version
2.17.2
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
I have tried running all version post 2.16.2, the crash occurs on all of them.
@nichwall commented on GitHub (Nov 24, 2024):
Is your database stored on a network drive? Looks like the database has gotten corrupted.
Does reverting to an older version work? So like 2.15.1 or 2.15.0, to make sure the downgrade migration is working? If the migration fails for any reason, the failed database is renamed to
absdatabase.sqlite.failedand the original database is restored so you can continue using an old version without losing data. If you try a downgrade and you get a similar error there is definitely something wrong with the database.@biuklija commented on GitHub (Nov 24, 2024):
The database is stored on the local drive, the config directory is in the same directory as docker-compose.yaml.
Versions 2.16.x run absolutely fine on the same database. So does the the downgrade to 2.15.0 and the subsequent upgrade to 2.16.2.
Upgrade to 2.17.x fails and dumps the
absdatabase.failed.sqlite.@nichwall commented on GitHub (Nov 24, 2024):
Thank you for confirming that you have your database stored on the same drive (storing it in a network drive can lead to corruption) and that downgrading is still working for you.
If you are willing to share your database privately (both the original and the failed backup of it), that would be very helpful in figuring out what is causing the migration to say the database is malformed. You can just zip both of them together to make the databases much smaller.
I am out of town for the week so I won't be able to investigate further for a bit.
@biuklija commented on GitHub (Nov 24, 2024):
Sure, where or how do you want the databases sent?
@nichwall commented on GitHub (Nov 24, 2024):
An email to the account on my GitHub profile or a DM on Discord works. You can either send it as an attachment or a link to download the zip from. I can forward it to other developers if you don't mind me doing that.
@nichwall commented on GitHub (Dec 1, 2024):
@biuklija sent me their database file. Running
PRAGMA integrity_checkon the file, looks like the media progress index got messed up prior tov2.17.0, so the 2.17.0 migration fails.Error is:
I attempted to rebuild the index using
REINDEX sqlite_autoindex_mediaProgresses_1;and just a plainREINDEX;, but I am now getting an error ofIt definitely looks like the database is corrupted. You mentioned that the database is located on a local drive and not accessed over the network. Have you ever ran multiple instances of ABS and pointed them at the same database or attempted to open the database in another program/script while the ABS server is running?
@nichwall commented on GitHub (Dec 1, 2024):
I was able to recover the database and upgrade to 2.17.3 using the following command in the terminal (without server running) to dump the raw SQL and recreate the database:
@biuklija commented on GitHub (Dec 1, 2024):
Not that I know of, but it is possible that I've run docker compose at some point while the image was running. I've also had an SSD failure on my server a few months ago, I was able to recover files, but the database could have been corrupted.
Thank you for your help, I've recreated the database and successfully upgraded it to the latest image. At least we've established that there's no underlying issue in ABS.