Navidrome 0.55.0 - Big Refactor (BFR) Release Notes (github.com)
from Deebster@infosec.pub to navidrome@discuss.tchncs.de on 10 Mar 2025 01:05
https://infosec.pub/post/24786882

Overview

Navidrome 0.55.0 introduces the highly anticipated Big Refactor (BFR), significantly enhancing core functionalities, and introducing robust new features. This release brings substantial improvements in handling file management and metadata usage and customization.

New Features

New configuration options

Deprecated/Changed configuration options:

Check the Configuration Options documentation for
more information.

Upgrade Instructions

  1. Backup Database: Before upgrading, create a backup of your current Navidrome database.
  2. Stop Navidrome: Ensure Navidrome is not running before proceeding.
  3. Replace Binary: Download and replace the existing Navidrome binary with the latest version (0.55.0).
    If using docker, pull the latest image.
  4. Start Navidrome: Restart Navidrome to automatically migrate the database schema. The upgrade process will trigger a full scan of your library, which may take some time depending on the size of your collection. While this full scan is in progress, please avoid using Navidrome, as the data will be unstable until the process finishes.
    Please don’t report any bugs until this full scan is complete (check the logs)

For detailed discussions and comprehensive insights into this update, refer to
our Big Refactor announcement and the original BFR Pull Request

#navidrome

threaded - newest

Deebster@infosec.pub on 10 Mar 2025 01:32 next collapse

I have this in podman with autoupdate, so I’m already running the new version - logs says startup took 833 seconds, so be patient when it upgrades.

I had to rename the ND_SCANSCHEDULE env var to ND_SCANNER_SCHEDULE (and restart again) but that was the only hitch for me.

nis@feddit.dk on 10 Mar 2025 06:11 collapse

I want to start using podman. Navidrome would probably be my first service. I would be very interested in seeing how you set it up. Have you shared it anywhere?

Deebster@infosec.pub on 10 Mar 2025 15:08 collapse

I’ve talked about my setup a little recently.

Here’s my quadlet file for Navidrome:

[Unit]
Description=Navidrome music server
After=mnt-files.mount

[Container]
ContainerName=navidrome
Image=docker.io/deluan/navidrome:latest
AutoUpdate=registry
User=1116:1116
UserNS=nomap
Network=navidrome.network
PublishPort=4533:4533
Environment=ND_LOGLEVEL=info
Environment=ND_SCANNER_SCHEDULE=1h
Environment=ND_BACKUP_PATH=/backup
Environment=ND_BACKUP_SCHEDULE=@midnight
Environment=ND_BACKUP_COUNT=7
Environment=ND_SESSIONTIMEOUT=72h
Environment=ND_BASEURL=""
Environment=ND_COVERARTPRIORITY="coverart.*, cover.*, folder.*, front.*, embedded, external"
Environment=ND_SPOTIFY_ID=aaaa
Environment=ND_SPOTIFY_SECRET=bbbb
Environment=ND_LASTFM_APIKEY=cccc
Environment=ND_LASTFM_SECRET=dddd
Volume=${HOME}/navidrome/data:/data:Z,U
Volume=${HOME}/navidrome/backup:/backup:Z,U
Volume=/mnt/files/music:/music:ro
HealthCmd=wget -q -t1 --spider --proxy off localhost:4533 || exit 1

[Service]
Restart=always

[Install]
WantedBy=default.target

There’s bit going on here, as I’ve got lots of optional stuff set up.

I don’t use a config file if I don’t want to/can’t do config reloading, which is why there’s loads of env vars - it’s just easier to have everything in one file.

Podman is running rootless, and Navidrome is running as UID 1116 within the container (and as 656476 on the host system as it’s a subuid of the podman user). Same for GID.

The Z,U bit on the volumes might need explaining - Z means apply a private SELinux label, U means set the volume’s UID+GID on the host to match inside the container (after mapping to user namespaces, that is).

nis@feddit.dk on 10 Mar 2025 16:54 collapse

Sweet! Thank you 😀

gid@lemmy.blahaj.zone on 10 Mar 2025 08:32 next collapse

I am so excited for this release! That persistent ID work really helps me out.

sabreW4K3@lazysoci.al on 10 Mar 2025 17:04 next collapse

I thought we’d get the UI update at the same time. Sadly not. But congratulations to Deluan for such a massive update. That said, I’m not a fan of making it a minor update in terms of SemVer

Deebster@infosec.pub on 10 Mar 2025 17:18 collapse

Hmm, good point - I guess he didn’t want to go to version 1.0 yet (I have no idea if 1.0 is on the roadmap or if it’s another project that will forever stay as 0.x)

abies_exarchia@lemm.ee on 10 Mar 2025 20:22 collapse

Breaking Changes

  • Artist favourites and artist ratings will be lost after the upgrade.

I spent a lot of time carefully favoriting artists. Is there any way to re-import or maintain these favorites after updating?

Deebster@infosec.pub on 11 Mar 2025 00:27 collapse

I can’t help much there, I’ve only favourited albums and they were handled by the upgrade script.

I assume the change is due to the persistent id feature, but I don’t know why the upgrade script couldn’t handle it (although I’m assuming it’s too error prone to do automatically because of duplicate artist names).

My guess would be you should open your pre-upgrade database and export a list, and then use that to add them again to the post-upgrade database. If you’d tagged your files with musicbrainz (Picard) then you should be able to find the PIDs without too much trouble.

Alternatively, you could change your settings to use the old matching “legacy” style if you don’t have tags that are useful for PID.

abies_exarchia@lemm.ee on 15 Mar 04:45 collapse

Hey just following up on this, I took your advice and got it working! For anyone seeing this in the future I took the old navidrome.db and called it navidrome_fav_artist_backup.db and then I loaded into the new database (after making a backup of it) with sqlite3 navidrome.db and then I ran this

-- Attach the backup database as "backup"
ATTACH 'navidrome_fav_artist_backup.db' AS backup;

-- Update annotations for favorited artists by matching on artist name
UPDATE annotation
SET starred = 1,
    starred_at = CURRENT_TIMESTAMP
WHERE item_type = 'artist'
  AND item_id IN (
    SELECT newArtist.id
    FROM artist AS newArtist
    JOIN backup.artist AS oldArtist ON newArtist.name = oldArtist.name
    JOIN backup.annotation AS oldAnnot ON oldArtist.id = oldAnnot.item_id
    WHERE oldAnnot.item_type = 'artist'
      AND oldAnnot.starred = 1
  );

-- Detach the backup database
DETACH backup;
.quit
Deebster@infosec.pub on 15 Mar 05:13 collapse

Congrats, and thanks for sharing.