I updated the container to the :develop tag.
After starting it it began a full rescan. Let’s just say it’s taking a while.
I’ll test if the speed while syncing to symfonium has increased when that finally finishes.
I don’t know why the navidrome scan takes so long. The PC doesn’t seem to be bottlenecked and has a direct 1GBit/s connection to the NAS.
I think there is a bug making the scan in 0.50 slower than usual. I’m investigating that. In the meantime, if your music was previously scanned and is available in the web ui, you can go ahead and test Symfonium sync.
I let it finish the scan anyhow before syncing to symfonium.
At the beginning the sync went really fast (2000+ artists/albums/songs per second).
When I looked at it closer to the end (at around 650k tracks already synced) each 1000 new entries took 4-6 seconds.
Example from the log:
192.168.0.28/navidrome/rest/search3.view?query=%22%22&songOffset=689000&songCount=1000&albumOffset=0&albumCount=0&artistOffset=0&artistCount=0&u=REDACTED&t=REDACTED&s=REDACTED&v=1.13.0&c=Symfonium&f=json (4640ms, unknown-length body)
So it definitely decreases in speed as the sync progresses but it at least managed to finish the sync within a couple of hours.
@Tolriq one thing I’ve noticed a couple of times now is that on my phone even after the sync is long done it still says “Finishing sync” and never finishes. Not even overnight like today (I went to bed before the sync was done). Force shutting the app and then opening it again gets rid of the message and all tracks are there so I doubt the scan is still doing something. I’ll try to activate debug logging the next time it happens.
You probably have left the option fetch additional metadata enabled . So this runs 1 query per album and 1 per artists to ask for that additional metadata, the limits of Subsonic. That can take a while as Navidrome will fetch that data at that moment too if it’s not already present.
You might be right. What exactly does it fetch? Is that documented somewhere? I’m usually content with my local metadata.
It fetch Navidrome data, depends on how you configure Navidrome.
With the big refactor of Navidrome I wanted to test how the latest and greatest version performs when compared to lms (which I’ve used for over a year now), but when I updated my existing compose from 2023 and deployed the container, it automatically started a full rescan in Navidrome, which failed after filling up the 7GB of free disk space that this VM has.
time="2025-03-12T02:54:29Z" level=error msg="Scanner: Error persisting changes to DB" error="database or disk is full"
time="2025-03-12T12:55:39Z" level=info msg="Stopping HTTP server"
time="2025-03-12T12:55:39Z" level=error msg="Scan failed" error="media file count: context canceled"
time="2025-03-12T12:55:42Z" level=info msg="Closing Database"
time="2025-03-12T12:55:43Z" level=info msg="Navidrome stopped, bye."
I don’t remember Navidrome filling up my disk like that during scans. Is that expected behavior? The db file itself is only 2,4GB.