Navidrome process is consistently using above 90% CPU with no activity in the command window.

[AHrubik]

version: 0.64.2 EXE
platform: Windows Server 2022

Recently noticed that Navidrome is using very high CPU time constantly. I was originally running it as a service but after noticing the high CPU time I converted over the command windows with no change. Have I misconfigured something? Any suggestions?

INI:
[default]
Port='45515'
MusicFolder='\\Music'
DataFolder='C:\tools\navidrome'
FFmpegPath='C:\tools\navidrome\ffmpeg.exe'
AutoImportPlaylists='false'
LastFM.ApiKey=
LastFM.Secret=
Plugins.Enabled='true'
Plugins.Folder='C:\tools\navidrome\plugins'
Plugins.AutoReload='false'
Plugins.CacheSize='500MB'
Agents='apple-music,listenbrainz'

[deluan]

After upgrading, it does a one time reprocessing of all your artwork. It may take a while depending on how many albums and artists you have in your library. Try setting LogLevel='debug', you should have more information.

[AHrubik]

Based on what I'm seeing there is a burst of processing right after launch, 20-30 or so items from the queue, and then it stops. CPU utilization remains high afterwards. Even with Deezer as the primary art processor it is still getting "stuck" it appears.

I added ".txt" extensions to all the profile files so github would see them in the attach window.

Queue
  KIND    PRIORITY  ITEMS
  artist  scan      322
  TOTAL             322

Sources
  KIND    SOURCE                ITEMS
  artist  absent                171
  artist  external:apple-music  77
  artist  external:deezer       2
  album   absent                219
  album   embedded              77
  album   folder                559

Absent (resolved, no image found)
  KIND    NO IMAGE  FAILED
  artist  171       0
  album   219       0
  (nothing retries these; 'artwork reprocess --source absent' retries both columns)
  (failed = gave up rather than being answered, so the ones most likely to resolve;
   'artwork reprocess --source failed' retries just those)

Config
  State:                fingerprint changed — stored artwork keeps the old resolution; run 'artwork reprocess --all' to apply it
  Stored fingerprint:   e5d7059d85126152
  Current fingerprint:  ef60c77ce8ed61f9
  Fingerprint inputs (changing any of these makes the stored artwork stale):
    CoverArtPriority:           cover.*, folder.*, front.*, embedded, external
    ArtistArtPriority:          artist.*, album/artist.*, external
    ArtistImageFolder:
    Agents:                     apple-music,deezer,listenbrainz
    EnableExternalServices:     true
    EnableM3UExternalAlbumArt:  false
    
    ```

[deluan]

Where are the profile files? You can also zip them.

If you prefer, send them directly to me: deluan @ navidrome org

[AHrubik]

send them directly to me: deluan @ navidrome org

done.

[deluan]

Thanks for the profiles, they nailed it. This is a bug in Go itself (the language Navidrome is written in): golang/go#79784. On Windows, when the library is on a network share (\\server\Music), one of Go's path functions goes into an infinite loop for artists that have albums directly in the root of the share. Each one of these artists gets the artwork processing stuck, burning one CPU core forever. That's why it does a few after a restart and then stops.

Go only fixed this in a version we don't use yet, so I'll add a workaround in Navidrome for the next release.

For now, you can avoid it by skipping the artist folder lookup. Add this to your navidrome.ini and restart:

ArtistArtPriority='album/artist.*, external'

It will still use artist.* images inside the album folders and fetch the rest from Apple Music/Deezer. From your artwork status, you don't have any artist images coming from the artist folders anyway, so you are not losing anything.

artwork status will say the config changed. Don't run artwork reprocess --all, it is not needed. Also, you can remove DevEnableProfiler now.

Let me know if the queue finishes after this.

[AHrubik]

Well thankfully I'm not crazy.... yet and thank you for supporting this.

Instant reduction in CPU usage from 90%+ to 30-50%. Queue emptied in under 3 mins. The process is using 0% whilst idle now.

you can remove DevEnableProfiler now.

done

Queue
  (empty)

Sources
  KIND    SOURCE                ITEMS
  artist  absent                265
  artist  external:apple-music  88
  artist  external:deezer       219
  album   absent                219
  album   embedded              77
  album   folder                559

Absent (resolved, no image found)
  KIND    NO IMAGE  FAILED
  artist  265       0
  album   219       0
  (nothing retries these; 'artwork reprocess --source absent' retries both columns)
  (failed = gave up rather than being answered, so the ones most likely to resolve;
   'artwork reprocess --source failed' retries just those)

Config
  State:                fingerprint changed — stored artwork keeps the old resolution; run 'artwork reprocess --all' to apply it
  Stored fingerprint:   e5d7059d85126152
  Current fingerprint:  7e17c897c59f2ecb
  Fingerprint inputs (changing any of these makes the stored artwork stale):
    CoverArtPriority:           cover.*, folder.*, front.*, embedded, external
    ArtistArtPriority:          album/artist.*, external
    ArtistImageFolder:
    Agents:                     apple-music,deezer,listenbrainz
    EnableExternalServices:     true
    EnableM3UExternalAlbumArt:  false
    
    ```

[deluan]

Hey @AHrubik, I have a fix for this in #6237. Can you please test it? Download this Windows build of the fix: navidrome-windows_amd64.zip, and replace your navidrome.exe with the one inside it.

Then:

1. Remove the ArtistArtPriority line from your navidrome.ini and restart Navidrome.
2. Queue the absent artists again:

navidrome.exe artwork reprocess --kind ar --source absent -c C:\tools\navidrome\navidrome.ini

The queue should drain and the CPU should go back to idle, like with the workaround. Artists with an artist.* image in their folder should now pick it up. You can follow it with navidrome.exe artwork status -c C:\tools\navidrome\navidrome.ini.

Let me know if this works for you.

[SiMoStro]

I had the same exect problem (music on a network share); the first provided workaround reduced the CPU usage, the above steps with the build solved it.