Thanks for the details. I’ve got a business trip this week but I will be able to try this out better in late June once I’m back home.
You’re welcome, let me know how it goes.
Sorry for the long gap — I wanted to bring complete data rather than a partial “seems fine” update.
What I did:
You asked (Post #23) to disable kodi-rebuild.sh, disable Jellyfin-Kodi, and run plain Kodi for a week. I instead did a full migration:
- Jellyfin-Kodi disabled — Kodi now scans SMB shares natively.
kodi-rebuild.shkept running, but I fixed a concurrency bug you predicted: it used to query the live DB before stopping Kodi; now stops Kodi first.- Nightly backup fixed the same way — JSON-RPC health check instead of live-DB access.
So initially I removed Jellyfin but hadn’t run the literal isolation test — my script still queried the live DB periodically. I’ve since gone back and run that test too (below).
Results after the migration: Errors did not stop. A self-inflicted concurrent-read incident reproduced your predicted mechanism with Jellyfin nowhere involved. Then a run of SQLITE_IOERR_SHORT_READ errors (auto-repaired), then a fresh SQLITE_CORRUPT structural event (manual restore). A handful of incidents over a couple months post-migration vs. one every few days pre-migration at the worst — real improvement, not elimination.
So I kept iterating:
Hardware: A full read-only pass over the entire eMMC — zero errors. A full memtester RAM pass — no failures. Four clean hardware signals total (sysfs registers, full extcsd dump, disk scan, RAM).
True isolation: Finally disabled kodi-rebuild.sh entirely for an extended stretch — your Post #23 test. Nothing touched the DB but Kodi the whole time. Zero errors. Library grew normally, no data loss. I’ve re-enabled kodi-rebuild.sh now as the ongoing safety net.
One thing I checked and ruled fairly unlikely, flagging just in case: Kodi here links SQLite 3.28.0, which falls in the vulnerable range of a known “WAL-reset” checkpoint/write-transaction data race (bug writeup, fixed in 3.51.3). I looked into it, but our symptoms don’t cleanly match — that bug is silent (no error raised) and needs aggressive manual checkpointing, neither of which fits our setup. Just noting the version is old regardless.
Your open questions:
- Does removing Jellyfin + our cron eliminate errors? The full isolation test came back completely clean — consistent with concurrent access being part of the mechanism.
- eMMC error-counter kernel? Still on the May 2026 build — is the staging kernel available now? Zero kernel-level
mmcblkerrors across all incidents; health registers unchanged; disk scan and RAM test clean, though not exhaustive. - SQLite upgrade? Not a strong lead per above, but the bundled version is old regardless — wouldn’t hurt.
I plan to slowly add back Jellyfin and backups scripts from here and see what happens. It’s still unclear to me what the root cause is here and why only one of my two Vero Vs has this behavior though I run the same config in both.
Thanks for the follow up. Let me think on this one.
So if you disable the cronjob, you no longer get corruption?
That would suggest the issue lies with the script
Yeah, I don’t think there is any underlying hardware corruption. Thank you for your help and support and sorry for the misdiagnosis initially. I still don’t understand why this only happens on one of my two Vero V’s but there must be some small configuration or usage difference that’s causing it.
When the kernel update with the eMMC error counter graduates out of the staging repo I’ll make sure to test that out some more. Not ready to install the staging kernel yet, don’t need to introduce more friction for my family 
Secondarily, it would be good if SQLite gets a version bump soon since the shipping version is a few versions and bug fixes behind.
Thanks again!
This is already planned.
Do give me an update when the next release is out.
Sam
1 Like