Errors while identifying added music, paused metadata improver: hints for roonlabs to troubleshoot

Support
1

There have been endlessly reported bugs regarding roon’s problem identifying new music that’s been added, or with the metadata improver pausing. I’ve encountered this myself for years on one machine running core (my backup server), never on another, then suddenly on the one with no previous issues. roonlab support’s stock answer is to blame the user’s home network configuration, even though roon obviously has network connectivity or else it couldn’t perform license validation, stream from core to endpoints, mount disks from the lan, stream live radio, stream qubuz or tidal, and so on.

Recently, I added a second ethernet card (NIC) to my server running ubuntu and roon core. After assigning the NIC a new IP address, verifying that the machine had both lan and wan access on both the old and new NICs and IP addresses, and disabling the old NIC (and it’s IP), I noticed the following familiar but dismal old bug rear it’s dreary head:

roon networking bug
roon networking bug1381×530 69.1 KB

Several interface and cable swaps, router tests and restarts, netplan restarts, roon service restarts, and machine reboots later, it appears that some roon component that accesses roonlab’s metadata in the cloud is persistently (and erroneously) stuck thinking the machine can only route using the old NIC IP address – or erroneously authenticates with the cloud service using the old lan IP as part of the machine’s fingerprint – as it would only work when there was a NIC with the old IP address. When the old NIC and old IP address was restored, everything resumed working again.

Now, a week later, with the machine still using just the old NIC and old IP address, track identification and the metadata improver have suddenly stopped working. Since my other machine running core went through this issue and remained brain-dead in this department for unpredictably long periods of time, I suspect my main core server will randomly get stuck in this state until I do a clean install of roon and/or ubuntu+roon.

Of course, the funny thing is that I can still swap my license between cores, still control the system from different clients, still stream to different endpoints, still point the library at disks hosted on other machines on the lan, and still stream live radio, showing that components of roon can still access the lan and wan. There are no network issues here, just some bug in some roon component or the data being used in some authentication protocol.

Changing hardware NICs like I did here isn’t the only thing that could trigger this bug. DHCP could trigger it on any user’s machine when a router assigns a new IP address to the roon core machine. That’s how I understand why my backup server became plagued with this problem. The new server, the one where I tried the second NIC, uses static IP(s).

3

This usually points to the router not resolving dns queries to Roons servers and happens with some ISPs more than others. Also clearing Roons cache has been knows to help in some cases. Have you tried changing the routers dns server settings so they use cloudflare 1.1.1.1 and Google 8.8.8.8 instead of the default isp ones?

4

[EDIT: This was posted on 8/12/2022 at 10:48 AM PDT but appears as if posted 9 hours earlier. Removed and reposted below.]

5

I agree was just suggesting it as something to try. These issues should be long behind Roon but unfortunately are not.

6

I seem to remember reading (but can’t find the thread) that DHCP reservation is a better option for the core than a fixed IP. I can’t see how it can make any difference, but might be worth trying.

7

It’s better in that the router should be in control of handing out ips and knows what ipaddresses are in use. DHCP allows this and reserving addresses on outer keeps DHCP active. If your setting fixed ip on devices with DHCP active on router it can lead to two devices with same IP address quite easily and thus clash and have network connection issues. Manual fixed ips should only be used if DHCP is not active or it’s only active on a given set of ipaddresses from the pool available and you use ones that are not controlled by DHCP. I doubt it would affect this issue at all though.

8

I do not believe it is helpful to continue feeding the narrative that the network is at fault, routers should be configured this way or that, and conjure up unsound technical reasons to keep this narrative going. All the evidence points elsewhere.

This is a bug in the component(s) of roon that implement those functions that stop working, not the lan configuration. Any network changes that “fix” it are just randomizing the environment and changing some edge case(s) that may or may not trigger the buggy behavior. How a host (or NIC) gets its IP address is immaterial to how the TCP/IP network stack works, and if there are two machines with the same IP address on the lan due to misconfiguration, most network operations on those machines will break, not just roon’s functions that are the subject of this bug. Discussing how the network may be the culprit if everything but the two items in this bug simply shifts responsibility for the bug from roonlabs support and roonlabs developers onto users.

Please, roonlabs, stop stabbing in the dark, step up, allocate a dev, and fix this already.

1 Like
9

As a further evidence that this is not a network issue, I offer the following:

Currently, roon says it cannot identify two new albums I just added and the metadata improver is paused, the same state as shown in the screenshot above.

Yet, after opening one of these unidentified albums, selecting “Edit…” from the “…” circle, then clicking the “Identify album” button, I’m presented with a list of albums and thumbnails that correspond to the album. When selecting one of these offerings, roon finds the first alternate is a perfect match and after I press “save”, it updates the album with full metadata.

So, roon can access roonlabs’ metadata servers, even though the new album scanner can’t identify the albums and the metadata improver is paused for, we’re told, lan/network issues that prevent roon from accessing roonlab’s metadata servers.

C’mon, roonlabs.

And to the person who moved this thread out of the “Support” sub-forum, please leave it here as this is an outstanding bug for which this information may be useful should roonlabs step up.

10

If you want support to help out you probably need to edit your original post to include the requested information …

Roon Core Machine

Networking Gear & Setup Details

Connected Audio Devices

Number of Tracks in Library

Description of Issue

It might also be useful if you could confirm that you have tried the suggestions mentioned in the KB article Resolving “Metadata Improver: Halted” error messages …

  1. Change the DNS that your network is using.

  2. Disable IPv6 on your router and Core.

  3. Remove any managed switches, WIFI repeaters, or powerline adapters from your setup.

  4. Disable any VPN, firewall, and antivirus running on your Core.

11

roonlabs has not resolved these two issues despite dozens of reports over the past few years. roonlabs continues to make recommendations about lan setup that, “If you’re seeing this type of issue frequently, it likely means that your Core machine or network is having trouble communicating with our servers.” per https://help.roonlabs.com/portal/en/kb/articles/resolving-metadata-improver-halted-error-messages. While an improperly configured network could be the culprit, then every function in roon that requires network access would fail. More specifically, as shown in my last post and observations, roon can get possible matches and load metadata for unidentified albums through the “Edit…” menu while at the same time it cannot do so while analyzing new music (and pausing the metadata improver) because, we’re told in all those problem reports, the user’s network is likely the problem.

It is absolutely essential to ensure that networks are working and good of roonlabs to help their users achieve that. My network works flawlessly without their assistance, and checks all their boxes anyways. But if 9/10 of roon’s network-based functionality works on a user’s premises, these two specific problem areas should also be trouble free. They’re simply flakey, and like many classes of bugs, disappear for inscrutable and uncorrelated reasons when the environment (i.e., network) changes.

What would the typical reaction be if your web browser worked most of the time but went through periods where pages wouldn’t load and the vendor told you that your network configuration was likely the problem, while your email and other net-connected programs still worked, all network diagnostic tools were thumbs up, router had no errors, your TV was streaming okay, and roon could load metadata when you added new music?

I have a number of older friends who are not very tech literate and are flummoxed by what seems simple to many. They try hard to follow instructions and get frustrated and blame themselves when things don’t work and can’t discern between when they’ve perhaps messed up and when vendors aren’t fixing problems. roonlabs ought to step up for all those customers, not just because “[I] want support to help [me] out”.

There’s no utility in me publishing details of my systems and network. There’s enough evidence for them to know where to look, reproduce, and find these two bugs.

12

With respect, if you refuse to provide the details regarding your system then there isn’t enough evidence for Roon to reproduce and find the bug(s). Clearly, the metadata improver is working for most people, but not for you, so something in your system, or the way in which it communicates with the server, is triggering the error.

Point taken, but see my previous point, i.e. this works for most people, so something about your (possibly) unique system and its connection to the relevant server is acting up.

So give them the info they need so that they can find and eradicate the bug.

13

Here’s my original bug report from 2 years, 4 months ago, complete with the network and system information that was requested by @noris at the time. There was no resolution. My bug report was split and merged into someone else’s bug report which likewise has never been resolved.

Here are search results containing about 160 reports of the “metadata improver paused” bug: Search results for 'metadata improver' - Roon Labs Community. Search hits include keywords describing the bug such as triangle, halted, circle, paused, update software. The handful marked as resolved were “fixed” by random series of reboots of different system components.

Here are hundreds of bug reports about errors adding music to the library, including keywords like stuck, spinning wheel, never finished: Search results for 'adding music to library' - Roon Labs Community.

No additional information about my current network configuration will get roonlabs off the pot on this. It’s clearly a bug in one small area of code that authenticates with their metadata provider backend, and which does this differently when doing batch updates from how any other component of roon authenticates. It’s probably some duplicate legacy code that hasn’t been maintained.

14

Thanks for the link to your original post, but I still don’t know if you’ve tried the suggestions in the KB article Resolving “Metadata Improver: Halted” error messages …

  1. Change the DNS that your network is using.
  2. Disable IPv6 on your router and Core.
  3. Remove any managed switches, WIFI repeaters, or powerline adapters from your setup.
  4. Disable any VPN, firewall, and antivirus running on your Core.

If you haven’t, then I don’t see the point in continuing to insist that Roon should just sort this out. You’re probably right that there is a bug, but if it’s one that can be navigated around by changing the configuration of your network, surely it’s worth a try?

15

I’m sorry that you don’t seem to be convinced by the evidence that this is not a networking issue. That both identifying new music and the metadata improver work from time to time on my network when the network hasn’t changed. That when the network does change and roon breaks, roon doesn’t start working correctly again when the network changes are reverted. That sometimes the bugs appear for long periods on one core while, when authorized, a different core doesn’t have these problems on an unchanged network. That roon connects to roonlab’s backend servers to authenticate my account and download metadata and identify music via the “Edit” and subsequent dialogs even when the bugs are manifest at the same time in the same running instance of the core.

I don’t believe providing the information you’re after will convince roonlab to put the necessary resources into fixing this, as they’ve chosen to let it fester for at least two years. But to satisfy your curiosity, I will tell you that I have either tried roonlab’s specific recommendations, or that my lan already meet particular criteria so there was nothing to be changed.

If one is highly concerned about security, they wouldn’t take all of roonlab’s recommendations, especially those in #4 in the list you quote.

16

This is for troubleshooting purpose, not for ongoing operation.

1 Like
17

Don’t think so. Directly before the list in Resolving “Metadata Improver: Halted” error messages it is stated that

If you’re seeing this type of issue frequently, it likely means that your Core machine or network is having trouble communicating with our servers. Below is a list of common troubleshooting steps that will help resolve this type of problem

If turning off your VPN “helps resolve this type of problem”, and the bug vanishes, and when you turn the VPN back on, the bug returns, the troubleshooting has revealed that the metadata improver won’t work over your VPN. Does one then have to find an alternative to using a VPN, say securely proxying through a rented machine in a datacenter in a different country, or reconfigure their VPN, or find a new VPN provider, so the metadata improver bug might go away, but only until DHCP hands out a different IP address, or if it’s Wednesday?

18

I have only ever seen the Error once , rebooting fixed it

I suspect that the answer lies in your specific config . I see reports of this error but if it were a widespread bug then this forum would be alight

Just my 2p

19

As @Mike_O_Neill mentioned, there’s little mention of this problem on the forum at the moment, so the issue is most likely related to the configuration of your problematic core - something about that device, or the way in which it connects to your “unchanged network” is triggering an edge case bug. If I were you, and I’ve mentioned this before, I would edit your original post to include as much info as possible regarding the devices in question, your network, connected audio devices and so on.

When you initially raised this problem in 2020 you were advised to try connecting your core to your primary router rather than going through a bunch of wifi extenders. Did you try that?

20

I wasn’t using any “wifi extenders”. I had a pair of routers running in AP mode acting as a wifi bridge. That’s very different.

After @noris suggested that they “believe” the problem occurs because of packet fragmentation, I analyzed the MTU from my roon core to the wan and saw no settings that would cause packet fragmentation. I asked him if they detected any service request timeouts in the logs that I sent and then the conversation went dead on his end.

In the interim, that machine has been put on the wired lan for a bit and roon was still showing the bug. Another roonlab network-at-fault hypothesis bit the dust.

The core server that suddenly got buggy prompted this thread has suddenly self healed after a few days.

21

Good news. If it happens again, try connecting it directly to your primary router.