Yeah. This has been a serious problem forever. There should be a way to turn off matching after X attempts. People with largeoddball collections are kinda screwed.
I have moved almost all of my Unidentified albums to another Storage Location so that I can turn it off when I don’t need/want it. It’s quite a process. I can give details in a Roon Software post if people want to know how I managed it. It cost me a day of screwing around (much more expensive than a Lifetime membership) and did not make me happy with the devs. //end off-topic
But can’t you just schedule when Roon does this metadata check? That was a recent update, so my understanding is that it should no longer matter how many unidentified albums you have.
Yes, but. I think I’ve seen it continue to work outside the “do stuff” window if it isn’t finished with a task. Not at all sure if I’m remembering correctly.
It also might factor into searches, but then again I’m not sure.
Yes, but Qobuz works without any restrictions, and I don’t use a VPN.
Moreover, this doesn’t correlate with the fact that a simple server reboot is enough to restore normal operation.
And there have been no responses to my clarifications and observations.
support require asking questions to eliminate, and there seem to be something amiss when Qobuz is not listed as available in Russia, but you have access to it.
I`m sure that Roon will follow up the support case, however these days have been more busy than normal.
We see connections in logs to Roon’s cloud services timing out and re-requesting. TCP streams are dropping mid-response. Image downloads are failing entirely. We don’t see evidence of memory spikes. These symptoms are consistent with problems introduced by georestriction.
That was why they asked if you were using a VPN. The cause of your issues has been shown to be network issues caused by georestriction - no evidence that it’s something in 2.65 of Roon Server.
Qobuz works throughout Russia without any restrictions. The only issue is the inability to pay for a subscription directly, but that’s not a big deal.
While Roon is a bit slow, the native Qobuz app works perfectly, both on a phone and a computer.
I’m tracking at least two more open support tickets with exactly the same symptoms.
I don’t think so. It’s why, when you schedule it, it makes you select a 4 hour window. It would make very little sense that if it did not complete the analysis and/or background work with in that window that it would continue to work outside that window. Maybe I am wrong, but it would be very strange.
This doesn’t jibe with the idea that restarting the Roon server is enough to restore normal operation. Don’t enable any blocking bypass services, don’t reboot the router, etc.
The problem isn’t some potential limitations, as support has at least a couple more open tickets with similar symptoms. However, in my case, they cited some potential limitations related to my geographic location.
A rollback to the previous roon server version plus library should show if there’s any connection to the roon software at all regarding geo blocking. In case the previous version works without connection rejection than there’s something different in how roon handles things now.
With version 2.64, everything was exactly the same. I was hoping this issue would be resolved with an update to the new version, as they’d improved RAM management. It became noticeably faster, but a day later, the problem recurred. I could blame my government’s restrictions, but at least two other people in this thread have encountered a similar problem.
As said, also depends on how much time passed between the very last time you listened with 2.64 without geo blocking and first time you tried with 2.65 unsuccessfully
I always try to use the latest versions of the software I use and update it promptly. In early April, I built a server on a NUC7i3 with 16GB of RAM, installed the latest version of Roon Rock 2.1 with server 2.64 (or 2.63 at the time), and this problem persisted from day one. Then Qobuz changed its CDN, which also led to some known issues.
Prior to this, the server was deployed on Sinology Nas, and I can’t say whether the same problem existed then, as Nas would automatically go to sleep at night and wake up in the morning, meaning it rebooted every night, and I didn’t encounter this problem.
Yes, I have created a support ticket a few days ago:
