WUD not detecting Navidrome updates

[tanderson1992]

I've been using WUD for a few months and just realized Navidrome updates aren't detected. According to the Containers page, it's monitoring hub.public for Navidrome. Navidrome has updated 3 times in the last 5 days, and those updates are live on Docker Hub. Are there any changes I can make to the compose so that WUD will detect these updates in the future? For reference, here is my compose:

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    user: 1001:100
    ports:
      - 4533:4533
    restart: unless-stopped
    environment:
      ND_BASEURL: https://[mysite]
      ND_IMAGECACHESIZE: 1GB
      ND_EXTAUTH_TRUSTEDSOURCES: 0.0.0.0/0
    volumes:
      - /share/docker/navidrome:/data
      - /share/nas/Music:/music:ro
    networks:
      - mynetwork
networks:
  mynetwork:
    external: true

[dkxmercury]

This is expected behaviour with the compose you posted, and it's a combination of two things rather than a bug.

latest is not a semver tag, and WUD deliberately never proposes a different registry tag for a non-semver tag. In app/watchers/providers/docker/Docker.ts, the tag candidate logic ends with:

} else {
    // Non semver tag -> do not propose any other registry tag
    filteredTags = [];
}

So the only way WUD can spot a change on latest is by watching the digest. And that's the second half: since 8.2.0 digest watching is enabled by default except for Docker Hub images (the changelog entry reads "Enable digest watching by default (except for Docker hub images)"). When you haven't set the wud.watch.digest label, isDigestToWatch decides in this order: a semver tag always returns false, then a configured default wins if you've set one, and otherwise it falls through to return !isDockerHub. latest is non-semver, and deluan/navidrome has no registry domain so it counts as Docker Hub, so it comes out false. The reason for the carve-out is that digest checks hit the Docker Hub pull API, which is rate limited.

Net effect: non-semver tag plus Docker Hub means no tag candidates and no digest check, so WUD has nothing to report. WUD actually tells you this - if you check your logs you should find a line like "Image deluan/navidrome:latest ... is not a semver and digest watching is disabled so wud won't report any update".

You have two good options.

Option 1 - keep latest and turn on digest watching:

services:
  navidrome:
    image: deluan/navidrome:latest
    labels:
      - wud.watch.digest=true

This works, but you'll get "new digest" notifications without a version number attached, and it does count against your Docker Hub pull quota. If you go this route and have a lot of containers, consider slowing the watcher with WUD_WATCHER_LOCAL_CRON.

Option 2 - pin to the semver tag (what I'd suggest):

services:
  navidrome:
    image: deluan/navidrome:0.63.2

Navidrome publishes proper semver tags on Docker Hub (0.63.2 is the current one), so WUD's normal semver path kicks in and you get real version-to-version updates, plus working major/minor/patch trigger thresholds. You don't need a wud.tag.include regex here either - WUD keeps only tags with the same prefix and the same number of numeric segments, so the pr-5790-style tags and develop get filtered out on their own.

One aside: if you're on 8.3.0 there's now a WUD_WATCHER_{watcher_name}_WATCHDIGESTDEFAULT env var if you'd rather flip the digest default globally instead of per container.

Worth noting the docs are slightly stale on this - the watchers page still says "By default, WUD enables it only for non semver image tags", which was true before the 8.2.0 Docker Hub carve-out. That's probably why this was surprising.

[tanderson1992]

latest is not a semver tag, and WUD deliberately never proposes a different registry tag for a non-semver tag. In app/watchers/providers/docker/Docker.ts, the tag candidate logic ends with:

I figured it was something like this, but other than Immich-server, which is pegged to a specific version, all 23 of my compose files have [some repository]:latest, and WUD detects updates for almost everything except Navidrome. I think the semver logic must be a little more complex than just the "latest" tag, because otherwise I'd be getting no update notices for anything.

I started this in discussions because I didn't think it was a bug but rather my misunderstanding of how the system works. FWIW, there are some "image is not a semver" warnings in my logs, but nothing specifically mentioning Navidrome. I turned on debug logs and didn't see anything more specific. Here's a small snippet of what I see in the debug logs during a cron job:

15:08:22.542  WARN whats-up-docker/watcher.docker.media: Image is not a semver and digest watching is disabled so wud won't report any update. Please review the configuration to enable digest watching for this container or exclude this container from being watched
15:08:22.551  WARN whats-up-docker/watcher.docker.media: Image is not a semver and digest watching is disabled so wud won't report any update. Please review the configuration to enable digest watching for this container or exclude this container from being watched
15:08:22.553 DEBUG whats-up-docker/watcher.docker.media: Start watching (container=media_navidrome)
15:08:22.553 DEBUG whats-up-docker/registry.hub.public: Get deluan/navidrome tags
15:08:22.558 DEBUG whats-up-docker/watcher.docker.media: Start watching (container=media_sabnzbd)
15:08:22.558 DEBUG whats-up-docker/registry.lscr.private: Get linuxserver/sabnzbd tags

The two warnings don't mention which image is not a semver, but they are referring to my media VM. Then it starts the list of containers that are watched on the media VM without any further errors. In the whole log Navidrome is only mentioned as being watched and never has an error associated with it.

I understand that I can workaround by pinning it to a specific version until an update is detected, but I'm still curious how image: lscr.io/linuxserver/bazarr:latest finds updates several times a month while image: deluan/navidrome:latest finds none.

[dkxmercury]

You've actually answered your own question here, the two halves just need connecting. The difference isn't the tag. Both deluan/navidrome:latest and lscr.io/linuxserver/bazarr:latest are non-semver latest. The difference is the registry.

Look at isDigestToWatch in Docker.ts. When there's no wud.watch.digest label and the tag isn't semver, the last line decides it:

return !isDockerHub;

and isDockerHub is true when the domain is empty, docker.io, or *.docker.io. So:

• deluan/navidrome:latest resolves to docker.io, so isDockerHub is true and the default becomes false. Digest watching is off, which is exactly the log line you saw.
• lscr.io/linuxserver/bazarr:latest is lscr.io, not Docker Hub, so the default is true. That's why bazarr gets picked up several times a month and Navidrome never does.

This was deliberate as of 8.2.0 ("Enable digest watching by default except for Docker hub images"). Docker Hub rate-limits aggressively, so watching digests there by default would hammer the API and get you throttled, hence it's opt-in for Docker Hub only.

The fix is the one WUD's own warning suggests: put the label on Navidrome.

services:
  navidrome:
    image: deluan/navidrome:latest
    labels:
      wud.watch.digest: "true"

Do the same for any other docker.io :latest image you want tracked. One caveat worth knowing: the code warns that digest watching on Docker Hub "may result in throttled requests", so if you enable it across many Hub containers on a short cron interval, keep an eye out for rate limiting. A handful of containers on the default schedule is fine.

[tanderson1992]

You've actually answered your own question here, the two halves just need connecting. The difference isn't the tag. Both deluan/navidrome:latest and lscr.io/linuxserver/bazarr:latest are non-semver latest. The difference is the registry.

Awesome, thanks! As I suspected, it's my lack of understanding behind the issue here. I'm not a developer and hadn't dug into the code to determine why the two latest tags behaved differently. I'll go enable digest for Navidrome.

[dkxmercury]

Glad it helped, that is what matters. Enjoy the working notifications.