Navidrome DB malformed #60
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?
Hecka issues, not really sure what happened, updated navidrome.toml
trying to take backups now so can rollback easier, because right now it appears I have to rebuild the database from scratch and import stuff seperately..
idk the database is working just erroring when getting to a certain part. prolly take a backup work out of another folder and leave that database live for now or something.
creating a fresh database rn, going through the scan, and just gonna build some sql to import the old data somehow. be better to have a fresh database i think. then start taking backups
easier said than done really lol, still haven't done this, been using the old database that's somewhat working kinda having issues with lidarr pulling new stuff though. albums missing like for tyler cassidy for example.
alright tired of the old database not being able to search what I want or find what I want getting annoying. So let's get this thing fixed today.
Actual Navidrome DB Metadata Migration - 2026-05-25
Workspace:
S:\Documents\prodigy\Coding-Programming\docker-containers\navidromeDatabases involved:
navidrome-working-with-errors.dbnavidrome.dbImportant backups created before writes:
navidrome.pre-metadata-migrate-20260525-150226.dbnavidrome.pre-metadata-migrate-20260525-160325.dbMain script used:
final_migrate.pyRemoved helper scripts:
change_path.pytest_ids.pyfinal_migrate.pyhandled mapping internally.What
final_migrate.pydoes:navidrome.dbschema and scanned library rows intact.navidrome-working-with-errors.dbassource_db.media_id_mapby matching source and targetmedia_file.path.user_name.Migrated user/listening metadata:
play_countplay_dateratingstarredstarred_atrated_atMigrated date-added/order fields:
media_file.created_atmedia_file.birth_timealbum.created_atalbum.imported_atUseful script commands:
Dry run full metadata migration:
Run full metadata migration:
Dry run only song/album date-added migration:
Run only song/album date-added migration:
Validation results after migration:
PRAGMA quick_check(20)returnedok.user=13annotation=235356scrobbles=2127media_date_different=0album_date_different=0Notes from troubleshooting:
navidrome.db.navidrome.db; stopping that process cleared the lock.database is lockedforUPDATE user SET last_access_at = ...during scanning is usually not critical by itself. It means Navidrome could not update the user's last access timestamp while another DB write was active.Scanner: Finished scanning all librariesandScan completed, so that specific lock message did not necessarily mean scan failure.Spotify.IDinnavidrome.tomlis deprecated and Navidrome logs that it is ignored. It can be removed from config later.Potential future carry-over items not migrated yet:
"""Migrate Navidrome persisted metadata into the current database.
The target database keeps its schema and scanned library rows. Source users are
matched by username; existing target users are not overwritten. New source users
are inserted with their old IDs when those IDs are available, then all related
metadata is copied through a source_id -> target_id user map.
Media/album date fields are copied by stable IDs/paths so Navidrome's generated
scan metadata stays intact while "date added" style ordering is restored.
"""
final_migrate.py