Missing / incorrect: Sivert Høyem ‎– Live At Acropolis


My ripped version (2 CDs, DVD not processed) is listed as “Unidentified”. The two options listed when "identify"ing the album have a duplicated track 8 on disc 2. Please check:

Best regards, AEB

Hi @AEB. Please would you post a screenshot of the duplicated track? Thanks.

Hi @joel,

This is how it looks like in Roon:

And this is what the corresponding location in the file system has in stock:

mini:Music $ find Sivert\ Høyem/
Sivert Høyem/
Sivert Høyem//Live At Acropolis
Sivert Høyem//Live At Acropolis/1-01 Lioness.m4a
Sivert Høyem//Live At Acropolis/1-02 Black And Gold.m4a
Sivert Høyem//Live At Acropolis/1-03 January 3rd.m4a
Sivert Høyem//Live At Acropolis/1-04 What’s On Your Mind.m4a
Sivert Høyem//Live At Acropolis/1-05 My Thieving Heart.m4a
Sivert Høyem//Live At Acropolis/1-06 Honey Bee.m4a
Sivert Høyem//Live At Acropolis/1-07 Prisoner On The Road.m4a
Sivert Høyem//Live At Acropolis/1-08 Into The Sea.m4a
Sivert Høyem//Live At Acropolis/2-01 The Boss Bossa Nova.m4a
Sivert Høyem//Live At Acropolis/2-02 Görlitzer Park.m4a
Sivert Høyem//Live At Acropolis/2-03 Give It A Whirl.m4a
Sivert Høyem//Live At Acropolis/2-04 Majesty.m4a
Sivert Høyem//Live At Acropolis/2-05 Sleepwalking Man.m4a
Sivert Høyem//Live At Acropolis/2-06 Handsome Savior.m4a
Sivert Høyem//Live At Acropolis/2-07 Moon Landing.m4a
Sivert Høyem//Live At Acropolis/2-08 Silences.m4a

Hope that helps.

Thanks. Our metadata in the Cloud doesn’t have this problem, so it suggests something locally, either in your file tags, or a problem in your library:

Please can you work with @support on this one?

Hi @support!

Any additional data that I could help with? When I look at the data using “Open folder as disk” in XLD, the meta data for this song does not look special.

Best regards, @AEB

Hi @AEB ----- Thank you for the report and the continued feedback here, both are very appreciated!

Moving forward, may I kindly ask you to please provide screenshots highlighting the file paths for both of the “Silences” tracks present in your example above.



Hi @Eric!

Here’s the file info for Silences:

Here is what the storage definition looks like:

And here is the result of a find from the Music root folder:

mini:Music $ find . -name “Silence
./iTunes/iTunes Media/Music/Dixie Chicks/Taking the Long Way/02 Easy Silence.m4a
./iTunes/iTunes Media/Music/Simon & Garfunkel/Tales From New York_ The Very Best of Simon & Garfunkel/1-01 The Sound of Silence (single version).m4a
./iTunes/iTunes Media/Music/Sivert Høyem/Live At Acropolis/2-08 Silences.m4a

This does, of course, not exclude that the meta data for Silences is contained in some other file. But what make me believe that the two entries actually belong to the same file is the fact that if I right-click on one, then both are highlighted and one file is indicated as selected:

Best regards, @AEB

Hi @Eric!

I now have a somewhat better understanding of what the problem appears to be (as it also occurred elsewhere):

  1. The original import had repeated tracks for the album (like I had the problem with a duplicated rip with an added sequence number)
  2. I deleted an excess track (whether through Roon or in the file system does not matter)
  3. The last track is then listed twice

From then onward, neither “Identify” or “Re-Identify” or temporarily removing the album or a rescan the library will resolve the problem. Some data seems to persist in the local Roon database.

It appears to be the necessary that the wrong data is present on the very first import of an album. I cannot reproduce the problem based on material that I had previously imported without an excess file.

Can you reproduce this behavior?

I’m running Roon Server v1.4 300 on OS X 10.13.3.

Best regards, @AEB

Hi @Eric:

Is there some background data cleansing within Roon database? It appears that both duplicate entries I mentioned earlier are gone by now.

So, problem gone - but mysterious to me. So some explanation would be appreciated.

Best regards, @AEB

Hi @Eric:

Have you had the chance to check whether my observation matches the current implementation. And if so, would it be easy to abandon that behavior in some future version?

Best regards, AEB

Hi @AEB — Thank you for touching base, my apologies for the slow response.

Continuing forward, I can certainly have our QA team look into this behavior for you as it is not totally clear to me how this behavior resolved itself. Do you have any information on how to reliable trigger this issue that I can pass along to the team?


Hi @eric - As stated, I wasn’t able to reproduce the behavior easily. My impression is that somethings “if left back” in the DB even if an album gets deleted. This obstructed my earlier attempts to do so. But I’ll try to identify a setting in which the behavior can be observed when I have some time to spare. -AEB

1 Like