We can reproduce this internally. The team now has a ticket in the pipeline tracking this problem. We’re reach out here when a fix is expected to be included in a release.
No need for further database uploads for those of you who were having trouble doing so. Thank you again for the report and for your help pinning this down.
This ticket remains in the pipeline, but we’ll notify users on this thread when the associated fix ships to Early Access and then a public, production release of Roon.
Hi, I’ve uploaded a problematic album (FLAC files) to the WorkDrive link for testing. Note that this album folder did not contain a local cover.jpg/folder.jpg — the artwork was only visible during the “Identify Album” step (pulled from Roon’s database) but was not retained after saving. Let me know if you need anything else.
· When I edit an album and click identify, the album will often be found in the list of match results. I select it. All the details for the artist and album and loaded when I click save, but the artwork always changes to a very generic black and white image, even though the artwork was showing on the match. I can supply screenshots to show this.
Not sure what you did, but there continue to be issus with identifying albums… although of course, the problem may lie with Qobuz and not Roon. Attached picture tells the story: Roon can correctly identify that there are two versions of an Album in my library (one from Qobuz, and one from a ripped CD), but is unable to group them under the same artist or to find the artwork. Disappointing!
Needless to say Roon is unable to “identify the album” (of the ripped CD version)… seems like a total mess, but impossible to tell if it is Roon’s or Qobuz’s fault…
… and to top it off, when I click on the Artist of the Qobuz album… it links to the page of a different artist that has the same first and last name… and includes in the Discography of this (wrong) artist’s the ripped CD, but NOT the CD of the Artist of the Qobuz album on whose name I had clicked… I’m pulling my hair…
We’ve been able to reproduce the mechanism in diagnostics, and it lines up with all three reports in this thread.
When an album is identified manually, Roon writes the album name, artist and track titles to the library album, but in the affected cases it does not persist the link to the metadata album behind that match. The name changes, so the album looks identified, but internally it still has no metadata album attached. That’s why the Metadata Preferences screen reports “No image” under Prefer Roon (thanks Matteo, that screenshot was the most useful clue in the thread): there’s no linked album for Roon to take artwork from. It also explains why clearing the image cache and switching the Artwork preference had no effect for Theodore, neither of those can help when the association itself is missing.
To be clear about where the artwork is: it isn’t lost or unreachable. In Theodore’s logs, the cover for this album downloads from our image service normally, at full size, every time it’s requested. It’s the album-to-image association that doesn’t survive the save, which is also why it shows correctly in the identification picker right up until you confirm.
A workaround in the meantime. For local albums, the most reliable fix is to give Roon an image in the album folder: save a cover as cover.jpg (or folder.jpg) alongside the track files, then set Album Artwork to Prefer file in the album’s Metadata Preferences. @Theodore_ECONOMOU, in your case the ripped folder contains only the FLAC files and no image at all, so there’s currently nothing for Prefer file to fall back on, adding one should restore the cover straight away. This won’t help for streaming-only albums, and we know it isn’t the answer, but it will get local rips looking right while the underlying issue is worked on.
This is still with the development team with the diagnostic detail attached. We’ll update this thread as soon as we have something to share, and we’d rather not leave you all re-identifying albums by hand in the meantime, if you hit a case that behaves differently from what’s described above, please do post it here, as the variations are useful to us.
Dear @benjamin thank you very much for your efforts in this matter. Appreciate the progress made and the helpful status update. Looking forward to full resolution. Best wishes.