I confirm that:

• I have searched the existing open AND closed issues to see if an issue already exists for the bug I've encountered
• I'm using the latest version (your issue may have been fixed already)

Version

0.55

Current Behavior

Hi!

Trying out the BFR, and it seems it's really unhappy with my poorly managed music collection, at least even less happy than it previously was. It completely stops scanning and fails to start, during the migration.

Expected Behavior

I could rename the file (and probably should, at this point), or move it out of the way, but really it feels like the database migration should just skip this, not crash.

Update: I tried to rename the folder, it didn't fix the problem, so the problem is probably more with the migration itself which fails to map the in-database path with on-disk.

I bet this is an encoding assertion issue, that assumes everything on disk is UTF-8, which is an often incorrect assumptions: on UNIX, typically, file names are arbitrary bytes and can contain pretty much everything but null and a slash, if i remember correctly.

Steps To Reproduce

I'm not 100% sure. I suspect that directory is already in the database so just creating it in 0.55 is probably not enough, you'd need to create it, have it added to the database, and then run the migrate, perhaps.

Environment

- OS: Debian Linux 12
- Browser: Firefox
- Client: Supersonic/Dsub/Tempo/Web, irrelevant

How Navidrome is installed?

Docker

Configuration

---
# managed by Puppet, local changes will be lost
version: "3"

volumes:
  navidrome-data:

services:
  navidrome:
    image: deluan/navidrome:latest
    user: 10000:10000  # should be owner of volumes
    ports:
      - "127.0.0.1:4533:4533"
    restart: unless-stopped
    environment:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info
      ND_SESSIONTIMEOUT: 24h
      ND_BASEURL: ""
      ND_RECENTLYADDEDBYMODTIME: "false"
      ND_LASTFM_ENABLED: "false"
      ND_AUTOIMPORTPLAYLISTS: "false"
      ND_ENABLESHARING: "true"
    volumes:
      - "navidrome-data:/data"
      - "/srv/playlists:/music:ro"
      - "/srv/mp3:/music/mp3:ro"
      - "/srv/incoming:/music/incoming:ro"
      - "/srv/espresso:/music/espresso:ro"
      - "/srv/audiobooks:/music/audiobooks:ro"

Relevant log output

navidrome_1  |  _   _             _     _
navidrome_1  | | \ | |           (_)   | |
navidrome_1  | |  \| | __ ___   ___  __| |_ __ ___  _ __ ___   ___
navidrome_1  | | . ` |/ _` \ \ / / |/ _` | '__/ _ \| '_ ` _ \ / _ \
navidrome_1  | | |\  | (_| |\ V /| | (_| | | | (_) | | | | | |  __/
navidrome_1  | \_| \_/\__,_| \_/ |_|\__,_|_|  \___/|_| |_| |_|\___|
navidrome_1  |                           Version: 0.55.0 (365df522)
navidrome_1  |
navidrome_1  | time="2025-03-10T03:28:51Z" level=info msg="Upgrading DB Schema to latest version"
navidrome_1  | time="2025-03-10T03:28:51Z" level=fatal msg="Failed to apply new migrations" error="ERROR go migration: \"20241026183640_support_new_scanner.go\": failed to run go migration: error populating folder table: open incoming/anne/Musique/Charles MINGUS/L\xe9o Ferr\xe9: file does not exist"

That folder is a latin1 file name (\ex9 is code 233 in decimal, é or é in HTML), which navidrome previously didn't crash on.

Anything else?

Thanks for the new release, it's exciting! I'll rollback for now. :)

Code of Conduct

• I agree to follow Navidrome's Code of Conduct