Philip Meyer;299869 Wrote:
>
> But it shouldn't be necessary to set COMPILATION=0 in most cases. I
> think that's because there are guest performers and no album artist has
> been set. So setting an album artist (or allowing an option for TPE2 to
> be regarded as Album Artist), would fix that problem.
>
It was required with MrSinatra's mp3 files which was attached with bug
8001.
Philip Meyer;299869 Wrote:
>
> What is the effect of setting COMPILATION=0 when there are different
> artists on tracks? I'm not sure what that would achieve - probably
> just cause other "issues" for people. I'm guessing it would cause
> groups of songs to be split into several albums with the same name.
It didn't split the albums with MrSinatras files, but I can't guarantee
that this won't happen in other cases.
I'm posting this here even though this is actually more developer
related, but it feels good to have the discussion in a single thread
since there already are some developers listening here.
I think the key code regarding all this can be found in two places:
1.
Slim::Schema::_postCheckAttributes:
- This is executed after each track has been read and created and its
purpose is for example to split albums separated by directory (the
Greatest Hit problem)
- This method also takes both the COMPILATION tag and ALBUMARTIST into
account. The compilation flag ha three states (0, 1, not set) that is
handled differently in some part of this code. In some places 0 and
"not set" is handled the same way, in some places it isn't.
- The code acts on a created track object and creates or updates the
related album and contributor(artist) objects, this also means that it
stores albums with COMPILATION tags into the database as compilation or
not compilation albums.
2.
Slim::Schema::mergeVariousArtistsAlbums:
- This is executed at the end of the scanning and as I understand its
purpose is to change earlier created albums into compilation albums if
they consists of more than one artist
- The mergeVariousArtistsAlbums code ONLY looks at albums where
compilation is not set
By looking at this code, my opinion is that we have following things to
take into account:
1.
If we want a checkbox to disable the "smart" detection logic which
isn't based on the COMILATION tag, it should be enough to just select
if Slim::Schema::mergeVariousArtistsAlbums should be executed or not.
The mergeVariousArtistsAlbums is fairly simple, so I don't think this
will have any side effect, but I haven't verified it.
2.
Any change in Slim::Schema::_postCheckAttributes will require A LOT of
testing. This part of the code is IMHO really complex and it is also
used whenever a track is written to the database, which will obviously
happen during scanning but also when you access a music file that isn't
in the database for example through Music Folder menu.
Due to all this, I would suggest that we try to stay away from changes
that affects this part of the code, the risk of causing other side
effects if just to large IMHO.
3.
The assigning of TPE2 to BAND happens in Slim::Formats::MP3, this is
defined by the code line:
Code:
--------------------
$MP3::Info::v2_to_v1_names{'TPE2'} = 'BAND';
--------------------
This assignment can't easily be changed to map it to both BAND and
ALBUMARTIST, so if we like to assign it to both I think we need to do
the modification in Slim::Formats::MP3 in the getTag function. Should
be fairly simple to do, but it might cause side effects in the
Slim::Schema::_postCheckAttributes method mentioned above since it
takes ALBUMARTIST into account in its logic. But since we don't
introduce a new tag, just a tag that already is handled by
SqueezeCenter for other formats, I don't think there is a big risk for
side effects. The advantage of this solution (assuming it solves the
problem), is that it will only affect MP3 files and there is no risk of
causing side effects for other formats.
So, providing a patch for 1 or 3, would probably be pretty easy for
someone that knows some perl programming. Implementing new advanced
configurable detection logic for compilations is a lot bigger work than
providing these two patches, so I think that kind of functionality can
be postponed a bit if we find a solution to the "urgent" problem.
Finally, the easiest solution would of course be to just let users use
the already existing logic with COMPILATION tags to override the
automatic logic in the cases where it doesn't work correct. I think
most users will have pretty few tags and no guest artists what so ever.
So I suspect this issue is mostly seen by people that feel it is
important that the tags contains as much information as possible and
also completely correct information. Most users don't care about tags
at all and will, as already mentioned earlier, probably just download
tags from freedb or similar services where all artists on an album in
98% of the cases is assigned to a single artist.
I can provide a patch for 1 and/or 3 if no one else wants to do it,
this assumes of course that we have some kind of common agreement that
a change is really needed and solution 1 and/or 3 would be good enough
for the time being. Since I don't have a good library myself for
testing this, it would also require that someone that either runs
SqueezeCenter under linux/mac or is willing to run it under ActiveState
perl under Windows is willing to help with the testing. I'm pretty sure
no one at Logitech will touch this issue in the near future unless they
get a someone verified patch to use. The main reason being that I think
they have other more urgent bugs and enhancements to take care of.
So, what solution will be good enough ?
--
erland
Erland Isaksson
'My homepage' (http://erland.homeip.net) 'My download page'
(http://erland.homeip.net/download)
(Developer of 'TrackStat, SQLPlayList, DynamicPlayList, Custom Browse,
Custom Scan, Custom Skip, Multi Library and Database Query plugins'
(http://wiki.erland.homeip.net/index.php/Category:SlimServer))
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=47297
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
