Can't reach metadata server[Solved]

Nothing changed my end that I can think of.

Roon waits a long time, then says “Search by Artist and Album” without finding them in the album name as usual. Has also once told me to check my internet connection, which is absolutely solid.

@mike any ideas? Or is it having indigestion?

I believe this is sorted now @Ludwig?

Dropping flag for @brian

1 Like

Yes sorted thanks to your help…

1 Like

I have the same problem since yesterday.
What is the solution to get metadata for albums again?

@Stephan_Groth Have you tried re-starting your Roon server? By the way, what OS is it running on?

I restarted the server multiple times and even uninstalled/reinstalled the server.
The server is running on my Synology DS 415+ and worked for weeks without any problem.
It has the latest version installed.

Can this be fixed in any config file?

The log contains this:

Error in web request… : NetworkError (Aborted.)
[metadatasvc] FAIL… (30013ms) NetworkError
[updatemetadata] neterror in updatemetadata: Result[Status=NetworkError, ErrorText=Aborted.]

[identification] <164143> Identifying album [???] with 11 tracks
[identification] <164143> identifier request id: f465f142
[identification] <164143> status: NetworkFailure
[identification] requeueing album that failed due to network (identifyalbum)

The the identification queue stopped processing two days ago.

@Stephan_Groth This is almost certainly an IP address caching problem as the metadata service IP addresses have changed - the question is where it is cached and how to flush/update that cached entry. Given that re-starting your Roon server has not solved the problem, this suggests a stale DNS cache entry somewhere in your network. The Synology NAS or your router are the obvious candidates.

My approach would be to work up the DNS chain.

  1. Have you rebooted the Synology? If not, please do that first and see if it fixes the problem.

  2. If rebooting the Synology doesn’t fix it, it’s likely that there’s a stale entry in your router’s DNS tables (or a more general DNS problem). If you are familiar with Windows or Mac/Linux terminals, typing ping (Windows) or ping -c 4 (Mac/Linux) may force an update in your router’s DNS tables.


From the router I get this information after flushing the DNS resolver cache:

Trying “

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52369
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 0



None of these two IP adresses is pingable.
The DNS resolver for the router is Google DNS.

I checked this even from different locations using different ISPs.
I get always the same result:

PING ( 56(84) bytes of data. ping statistics —
5 packets transmitted, 0 received, 100% packet loss, time 4033ms

The DNS query delivers the same pair of IP adresses on different DNS servers (checked with dig).

I get the same IP addresses (and no I can’t ping them either).

Have you restarted the Roon server since flushing the DNS resolver cache?

Yes I did. The result is unchanged:

[updatemetadata] neterror in getmetadata: Result[Status=NetworkError, ErrorText=Aborted.]

Are you sure the service is running, listening at the correct port an no WAF is blocking the requests?

Yes, the metadata service is working for me. I restarted my server just to make sure that it took the IP addresses you posted above.

Did you check it over the Internet or via a LAN connection?
Has there been any change last Tuesday?

Whatever I can do to help solving this problem, let me know.
For me the metadata service is unusable since Tuesday.

Understood and thanks for your patience. I’ll discuss this with the rest of the team and someone will get back to you.

I think I found a workaround for the problem:

The metadata service is working again if I disable jumbo packets in my Synology DS.

I suppose something in your infrastructure changed (load balancer?) that leads to a changed network communication.

In the long term I’d like to reactivate jumbo packets in my DS, because this enables the high data transfer rates in the LAN. Please check what changed on Tuesday and let me know, when I could test with jumbo packets activated, again.


Hi Stephan,

Thanks for this information. We’ll take a look.