![]() |
SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Support (https://forum.jellyfin.org/f-support) +--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting) +--- Thread: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change (/t-sqlite-database-corruption-in-jellyfin-10-10-6-sudden-failure-without-system-change) |
SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - gvns - 2025-03-05 Environment
Issue Description My Jellyfin instance has suddenly stopped working - specifically, I cannot get playback to function at all. The system was working normally last night, but today it's failing with database corruption errors. What's particularly concerning is that this happened without any:
Error Messages The primary error I'm seeing is: [ERR] Microsoft.Data.Sqlite.SqliteException (0x80004005): SQLite Error 11: 'database disk image is malformed'. This appears to be a SQLite database corruption issue. Interestingly, I've recently encountered similar SQLite database corruption in other "arr" applications in my stack, suggesting there might be a common underlying cause. In all the other cases, I simply restored from a .bak of the .db though the fact that this is reoccurring across several different containers is concerning. Full log from today: https://forum.jellyfin.org/attachment.php?aid=6979 Troubleshooting Attempted So far I've identified the error in logs but haven't attempted recovery procedures as I wanted to get community input first. I've found some potential recovery commands from this Stack Overflow post that suggest running: to check integrity: Code: sqlite3 library.db "PRAGMA integrity_check;" and I get the output "ok" - which does not tell me much. or to recover (have not tried this yet) Code: sqlite3 broken.db ".recover" | sqlite3 new.db However, I'm hesitant to try these without guidance as they may just be band-aid solutions if there's a more severe underlying issue causing database corruption across multiple applications. Questions
Additional Information - I am using an SSD dedicated for my container appdata - this does make me wonder if that is suspect. The SMART Info does not seem to imply it is at fault. Thank you! RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - theguymadmax - 2025-03-05 Post the full server log. RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - gvns - 2025-03-05 Whoops, I did not attach that log as I thought. https://forum.jellyfin.org/attachment.php?aid=6979 RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - TheDreadPirate - 2025-03-05 Code: MediaBrowser.Common.FfmpegException: FFmpeg exited with code 254 Can you share the ffmpeg log? Also, what are your hardware specs and did you pass in the GPU into the container? RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - gvns - 2025-03-05 Of course. In terms of hardware, I do not have a discrete GPU. Instead I am using the iGPU ( Intel UHD Graphics 730 ) from the Intel i5-12400 CPU I have here. I pass that iGPU device into the container using /dev/dri for iGPU transcoding. more detail below. # Unraid Server Hardware Summary ## CPU - Processor: Intel Core i5-12400 (12th Generation) - Cores: 6 physical cores, 12 threads total (via Hyper-Threading) - Base Frequency: ~800 MHz (idle frequency, boosts higher under load) - Cache: 18MB (18,432 KB) - Microarchitecture: Alder Lake (model 151) ## Motherboard - Manufacturer: ASUSTeK COMPUTER INC. - Model: ROG STRIX B760-I GAMING WIFI - Chipset: Intel B760 ## Memory - Total RAM: 32GB (2 x 16GB) - Type: DDR5 - Speed: 4800 MT/s - Manufacturer: Lexar - Configuration: 2 DIMMs populated out of 2 total slots - Maximum Capacity: 128GB supported ## Graphics - Integrated GPU: Intel UHD Graphics 730 (Alder Lake-S GT1) ## Network - Onboard Ethernet: Intel I226 LAN (disabled according to baseboard info) - Network interfaces were detected in ip addr output ## System Type - OS: Unraid OS - Docker Support: Yes (Docker service is running) Here is a zip of all my logs: ![]() A snippet from them, what I think threw that log error: Code: ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers That was me attempting to test playback, so may not be super useful for troubleshooting purposes. Since this initial post, I ran a scan of all media libraries and now have restored playback functionality. I noted the watch state of some items seemed to be reset. My bigger concern here is having another corruption of the database. Are there some best practices or ideal backup processes to use? Though before that understanding why this occurred is my focus. That may not be possible though given the limited logs at hand. for context, lscpu and lspci output: lspcu: Code: Architecture: x86_64 lspci Code: 00:00.0 Host bridge: Intel Corporation 12th Gen Core Processor Host Bridge (rev 05) RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - TheDreadPirate - 2025-03-05 Did you relocate your media storage? That is the only explanation for why scanning your libraries resolved the issue. Code: Error opening input files: No such file or directory Backing up a docker install of Jellyfin is pretty simple. Stop the container, make a backup of the directory that contains /config and /cache. /cache is optional, but I've found that it makes the initial startup after restoration much smoother. RE: SQLite Database Corruption in Jellyfin 10.10.6 - Sudden Failure Without System Change - gvns - 2025-03-06 (Yesterday, 11:55 PM)TheDreadPirate Wrote: Did you relocate your media storage? That is the only explanation for why scanning your libraries resolved the issue. Good to know. I found a few different scripts to do this, this one in particular seems decent: laughingman77/Jellyfin-Backup-Restore: Scripts to backup and restore Jellyfin data. I will probably fork that and improve it a bit for my use case and add it to my regular backup script schedule. Considering I am back up and running I am going to call this "solved", though I have a gut instinct that I will probably run into some corrupt sqlite db stuff again. There are quite a few topics around this here/reddit/stackoverflow that do not seem to have much in the way of a root cause and instead just focus on recovery. I am not savvy about sqlite db maintenance, though from what I do know I have been using it properly (allowing it to shut down gracefully, etc) Thanks to the both of you for taking the time! |