Bugzilla – Bug 7869
multi-disc albums are not geting merged anymore
Last modified: 2014-08-06 09:39:38 UTC
self-descriptive. I've noticed it couple of days back. Not sure when it actually got introduced. Can bi-sect per request
Please attach sample files to reproduce.
Note this is a result of the fix for bug 4361.
Test this behavior when the user uploads the files, and also test the bug Andy refers to.
Andy, I've sent some details over an e-mail. Please let me know if you need anything else.
Ok, after playing a while around Schema.pm I've discovered the following The check below is indeed the reason merge does not work for me anymore: if ( blessed($contributor) ) { # Bug 4361, also match on contributor, so we don't group # different multi-disc albums together just because they # have the same title my $contributor = $contributor->id; if ( $isCompilation && !scalar @{ $contributors->{ALBUMARTIST} } ) { $contributor = $self->variousArtistsObject->id; } $search->{'me.contributor'} = $contributor; } Seems reasonable, but enforces me to do one of the 2 things a) add _non standard_ TCMP tag (COMPILATION for ogg/flac) b) add TPE2 tag to mp3 (ALBUMARTIST for ogg/flac ?). Option (b) looks better (and would allow album to appear not only under VA but also under corresponding artist), but TPE2 is being mapped to BAND role and when primary contributor is being fetched ALBUMARTIST role is being used. # The "primary" contributor my $contributor = ($contributors->{'ALBUMARTIST'}->[0] || $contributors->{'ARTIST'}->[0]); Typo? Or may be some other _standard_ mp3 tag have to be mapped to ALBUMARTIST role, or may be all 3 roles have to be checked here (BAND/ALBUMARTIST/ARTIST) ? Also: # Bug 2066: If the user has an explicit Album Artist set - # don't try to mark it as a compilation. So only fetch ARTIST roles. .... This just asking to be configurable ....
Yes, you need a compilation tag. You're right it's non-standard, but iTunes uses it so that makes it basically a de-facto standard.
I can do that (set TCMP tag). But it does not solve the issue with TPE2/ALBUMARTIST. Also, would be nice if scanner could guess ALBUMARTIST role based on directories layout. For example on one of last stages for albums which do look like compilations one could try to match normalized path elements (uppercased, underscores to spaces etc) with the list of available artists. That alone would give pretty high rate of good guesses, I think.
Nick some sample files showing this behavior would be welcome so we could trace the handling of all the tags within.
Created attachment 3273 [details] challenge Ok, here is the challenge (with artificially introduced complexities: clashes in names) Ideally w/o any extra hints this should be organized into 6 albums, 4 of which are multi-disc compilations. It's definitely possible to do if directory structure will be taken into account when grouping. Really 'fancy' trick would be to recover AlbumArtist for Mix albums based on artist present in tracks located in unsorted area and list these albums under corresponding Artist (in addition to VA). But that's far beyond what's really needed... Current state of things is close to unacceptable: I can understand taking non-standard tags as a hints, but to rely on them.... One of the reasons I bought squeezebox and not some other streamer was that all software is opensource and can run pretty much everywhere. Have you heard about iTunes for Linux? Or may be some other 'user friendly tag editor' which handles iTunes specific tags? I did not... Sorry if it came out wrong (I'm obviously not a native English speaker) - I really like the product and ready to offer help as much as needed/I can afford given my time constraints ....
s/I really like the product/I really like the product overall/ And please accept my apologies for being too expressive/emotional yesterday.
Raised a query on this one on the forums: http://forums.slimdevices.com/showthread.php?t=48687 It is a bug in 7.01 and 7.02 releases as well.
Bug 8001 added an option for treating TPE2 as Album Artist, you might want to try again with that option enabled.
OK - I've upgraded to 7.1 and changed the TPE2 setting to 'Treat TPE2 MP3 tag as band'. Had to restart the PC for the change to take proper effect. The rescan started automatically on reboot. Still have multi-disc albums repeating in the album list. Changed the setting to 'Treat TPE2 MP3 tag as Album Artist'. Still no change (23 additional discs added to my 323 albums each time - the exact number of multiple discs under VA). Am uninstalling SC7.1 completely and installing 7.0 again as I know this works (this fixed the same problem 2 days ago). FYI: My music is 100% FLAC.
Multiple artwork files disables merging! Merging works fine as long as there is only one cover art file for multi disc sets! I'm using a custom artwork file name (artwork.jpg). If I have this file in both directories of a multi disc set, SqueezeCenter (b20460) treats the disc as two separate discs even though the setting to group multi disc sets is set correctly and the DISCNUMBER that is set accordingly. E:\Music\Electric Light Orchestra\The Very Best Of The Electric Light Orchestra (Disc 1)\artwork.jpg E:\Music\Electric Light Orchestra\The Very Best Of The Electric Light Orchestra (Disc 2)\artwork.jpg Removing the artwork file from the second directory makes merging work correctly! Oh, this is with SqueezeCenter running on Windows Vista. IMHO this is more of a "feature" than a bug. It would be nice though if SqueezeCenter realized that the two artworks are identical and it would ignore the second one. (If the artwork files are *different* it makes sense to treat the disks separately for presentation reasons).
This is a reminder that this bug is to QA for 7.1. Please review these bugs!
I have multi-disc sets with the same artwork in each folder (cover.jpg) and don't have this problem. I also don't see this problem in SC7.0 (just 7.01,7.02 and 7.1) - and it only occurs in the Various Artists Folder with multi-disc sets. I've followed all the ripping guidlines in the forums and have a well structured music library directory system (artist/Album, 'Various Artist'/Genre/Album)
Targeting for 7.2. Assigning to Steven for him to reconcile this behavior into his tagging master plan.
OK - I've now managed to sort this out with my DB with FLAC files by adding an additional tag to the meta data on all FLAC files: <COMPILATION>=1. Perhaps this is the answer and needs to be added to ripping instructions?
bug 8001 addresses the mp3 / tpe2 issue. as to the merging issue, are you merely masking it by setting the comp tag, or solving it?
I beleive this tag should be set. When I convert FLAC2MP3 for itunes and ipod use I always have to set this in the itunes library to get it to treat compilation tracks as part of a single album (when there are various artists). I use EAC to rip my discs to FLAC. This automatically manages much of the various artists logic (such as changing the directory structure etc) but it doesn't set this tag. I haven't bothered to amend the rest of my VA albums (the ones that are single disc) as these are being handled normally.
Changing target to 8 and adding keyword so this will be considered for new schema.
*** Bug 10190 has been marked as a duplicate of this bug. ***
this thread demonstrates why the logics aren't the best way to handle these situations, at least not in a mandatory way. regardless, good example of things going wrong: http://forums.slimdevices.com/showthread.php?t=68051
Nick et al, is this bug still valid in any way? it seems to me its resolved.
There's still the issue of requiring a COMPILATION tag in order for multi-disc compilations to be correctly merged. Until that can be resolved, this bug should remain open.
I ran in to this problem recently after installing and starting to use squeezeboxserver. Adding the TCMP field to the id3 tag for mp3's solves the problem for me; however, this seems redundant since for a multi-disc collection I am already using the TPOS field to specify disc number. Since TPOS stands for "Part of a Set", the correct usage would to be use that tag exclusively for compilations. I don't have a problem with setting a compilation tag, but it seems unnecessary since the needed information is already contained in the TPOS field. In the same way, I think DISCNUMBER would only be used for Vorbis Comment tags for multi-disc albums. I am using squeezeboxserver 7.5.4 on Debian Linux.
You can't assume a multi-disc album is a compilation, though. Many single-artist albums span multiple discs.
And vice versa, many compilations are only on a single disc. :)
can someone please define what the current issue still is that this bug represents? what is "wrong?" what circumstances create it?
(In reply to comment #27) > You can't assume a multi-disc album is a compilation, though. Many > single-artist albums span multiple discs. I hadn't thought of it that way, but I don't see why that should make a difference. The grouping option in Squeezebox Server is to group multi-disc sets as a single album. It shouldn't matter if it is a compilation or not. The current problem is that multi-disc compilations don't group unless the compilation tag is set. If it's already specified as a multi-disc set and the album name is the same for all tracks, why should Squeezebox need to know if it's a compilation or not in order to properly group?
(In reply to comment #29) > can someone please define what the current issue still is that this bug > represents? what is "wrong?" what circumstances create it? As it stands, using Squeezebox server 7.5.4, multi-disc compilations are not grouped together as a single album unless a compilation field is set in the tag: "TCMP:1" for id3 and "COMPILATION=1" for vorbis comment (I have only tested id3). Multi-disc albums by a single artist or where enough of the tracks are by the same artist do get grouped together as a single album. I think the solution is either to require that the compilation field in the tag be set or to update the code to be able to handle multi-disc compilations without having to set an extra field in the tag.
Unassigned bugs cannot have a priority.
Haven't seen this any more in a long time. Considering fixed.