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:
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).