SQLite database broken (database disk image is malformed) #169
Answered
by
saschabrockel
saschabrockel
asked this question in
Q&A
-
First Check
Homebox Version0.13.0 What is the issue you are experiencing?Sometimes my homebox frontend was not working anymore and data was not loading. I was wondering why and saw this in the logs randomly. A few moments later it worked. I have no problems with my disk. I got 100 containers running with all appdata on it and never had issues. And now it got even worse out of nowhere and broke my whole database... How can the maintainer reproduce the issue?Absolutely no idea. I'm running this container on unRAID on a cache share. No other application has access to this path. I started with 0.12.x as version. Edit: I got an idea. It might be because I added the exact same picture as file multiple times. I got a smart thermostat in different locations. So I added it in different locations and uploaded the same picture with the same name and size for 3 items. I guess that corrupted my database... I tried to get it back but does not look good... DeploymentDocker (Linux), Unraid Deployment DetailsNo response |
Beta Was this translation helpful? Give feedback.
Answered by
saschabrockel
Dec 30, 2024
Replies: 3 comments 1 reply
-
|
The app is unusable for me. Again after a while in the container the message I really wanted to use this app and already spent much time filling the database... this is a real showstopper. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I am having the same (homebox isolated) issue. Not sure where to begin to debug. Really annoying as I am using it heavily. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
The same picture getting uploaded would not impact the database operations, every upload of the file would generate a new automatic GUID and replicate the image (with a different name). So, there shouldn't be any issues there. SQLite has many ways it can break unfortunately so it's hard to pin down the exact reason why it might be happening to you. They call it "resilient" but in my experience it's easily the most finicky database out there (one of the reasons we're adding Postgres support for v1). SQLite even has documentation on all the different ways their database could end up corrupted: https://sqlite.org/howtocorrupt.html It's also possible (although I somewhat doubt it), that the Go implementation of SQLite is bugged in some way causing issues. https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/57872238 Has many potential corruption recovery options that may work. Unfortunately, my own SQLite recovery experience is significantly lacking so I can't be of much help on that side of things. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
In the end for me it fixed it with direct access instead on a share. Before I used /mnt/user/appdata in the unRAID context. Since I use /mnt/cache/appdata directly, it works. It's slow with 1800 items with pictures but never broke again. |
Beta Was this translation helpful? Give feedback.
Answer selected by
tankerkiller125
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the end for me it fixed it with direct access instead on a share. Before I used /mnt/user/appdata in the unRAID context. Since I use /mnt/cache/appdata directly, it works. It's slow with 1800 items with pictures but never broke again.