Duplicate albums #611
Comments
Please run
I guess you mean the |
|
Here's one where one of the songs unfortunately got left out because of capitalization: Songs 01-12 are in one album Song 13 ended up in its own album If that's the cause, would it be possible to handle these cases somehow? Or do I just have to manually fix every one? Here's another example where I see no difference in the album/artist, but apparently there's some "compilation" tag that's only present in the first song. Song 01 is in its own album Songs 02-11 are in the other album |
|
At least deleting the compilation tag resolved that issue, so I'm guessing fixing the case of the other one will fix that as well. Is there some better way to determine which songs are in the same album, like just being in the same directory and having identical-ish (trim whitespace, ignore case) album? Or are there cases where it has to be strict like this? I guess it's my fault for having such sloppy tagging on my music, but I haven't noticed before because previous software hasn't cared. |
|
I believe the current rule is:
If you keep all the tracks of an album in one folder, this SQL will show you which folders have been divided into different albums: If your tracks are organized into disc subfolders, you'll have to replace I hope that works and helps ;-) |
|
Well indeed it is always better to fix tags (and even better to use musicbrainz identifiers) |
|
I get this problem too. In my case it is happening because of inconsistent "composer" tag across songs in an album though this should not cause any problems. If I run this query: SQL queryselect
t.id as track_id,
t.name as track_name,
t.artist_display_name,
a.id as artist_id,
a.name as artist_name
from
track t
join track_artist_link tal on t.id = tal.track_id
join artist a on tal.artist_id = a.id
join release r on t.release_id = r.id
where
r.name = 'Hot Thoughts';I get this output: OutputTangential but there should be a unique index on track_id and artist_id here. If I filter out rows where This is consistent with how LMS is grouping the songs into albums:
Here is an example ffprobe output for one of the files (Tear It Down) which shows that the artist name comes from the composer tag: ffprobe outputEDIT: Wanted to add that there are five albums that appear for Hot Thoughts, equal to the number of distinct artist_ids in the second SQL output
|
That the split aligns with composer is a red herring, it's actually because the publisher/label tag varies across tracks. |
How do you know that? And what is the publisher label/tag in the ffprobe output I shared? If I know what tag you are talking about I can check your claim. Edit: I am an idiot. The tag is right there. Let me check. Edit 2: Yeah you are absolutely right. Thanks for pointing it out. |
;-) Glad you got it sorted. |
|
I can open a new issue for this, but I'm fairly certain that there's a bug in the label parsing for mp3s. To avoid having albums split by label/publisher, I'm using actions in mp3tag that always set Label and Publisher to the same value (which is decided by what is present). If label is present, both are set to that, if only publisher is present, both are set to that. Which is correctly parsed for flac files where it is stored as But not for mp3s. In the case of mp3s, the label is saved as
|
|
Ah, this reminds me another issue: if the same info is stored into two different tags (like a custom one and an official one), taglib can end up presenting both values under the same tag. Lms then consider they are multi-valued. |
|
Just an update, since I started this. I gave up and found this software called Picard. I'm in the process of updating all tags of all my music. Maybe it will work better then =). Only problem is that LMS doesn't seem to like it when I change tags while moving/renaming a song, as I will lose playcounts and ratings. So I'm updating the tags first, rescan, then move/rename, and rescan again. |
It looks like v3.64.0 should address that! a3dfc08 |
It says "if the track file just moved", but in my case that's already working. What's not working is when it's not just moving, but also getting its tags changed. |
Sorry, I misunderstood. Maybe @epoupon can confirm. |
|
On file moves:
|
Even so, a multi-value for the label should not split each track into a new album, or should it? Here are the tags of 2 tracks from my screenshot above, where each of the 15 tracks was considered its own album: |
|
No indeed... Would you mind sending me these two files? [email protected] |
|
No problem. I've uploaded them here. Password is |
|
Ok thanks! I confirm the issue is because of these bad label handling... Well, deduping the values seems to fix, but I think I will raise an issue on taglib side first |
Importing songs that (as far as I can tell) have identical album and artist data, are sometimes split into two albums with identical names. I checked the database, and the table "release" (which I assume is the albums) contains multiple duplicate rows where all columns (except id) are identical.
What info do I have provide to help recreate the issue?
Speaking of this topic, I noticed that the "release" table also has a column for the artist. If a single album has songs with different artists, how are those handled?
The text was updated successfully, but these errors were encountered: