>If we want a small quick fix for 7.6, it would be possible to just
>change the default name used in the setting from "Various Artists" to
>"Compilations" and that should minimize the risk for collisions, and we
>can later in 7.6++ do the bigger change.
>
That will however mean that when albums are auto-detected as compilations, the
album artist would be set to "Compilations" instead of "Various Artist". i.e.
there is I think an underlying problem that the setting defining the name for
compilations is used for two separate things; name of the special artist entry
used for displaying a list of compilations (irrespective of the album artist
name on each compilation), and also used for the name given as the album artist
when making an album a compilation.
If the special entry name was hard-coded (via a localised string) to
"Compilations", this would reduce confusion.
>Of course, even easier would be to just ask the users that have problem
>to change the setting to "Compilations" and instead focus on the real
>solution in 7.6++.
Which is what users do, and the conclusion I came to with bug report 9523.
> I suspect this is what we will end up with for 7.6
>as there are other a lot more serious problems with higher priority
>which needs to be solved before this.
>
Yes.
>Assuming everyone agrees, what's the next step ?
Make a patch, and try it out. Prey that a patch attached to the bug report
would be applied sometime this century. I can't see that happening - will be
hard to convince a logitech developer.
>I'm guessing no one from Logitech monitors this thread ?
I don't think there's many developers left in Logitech that monitor any thread
:-(
I think the query to get the list of artists, avoiding logic that looks at
album compilation property could be:
SELECT distinct c.*
FROM contributors c
join (
select contributor from contributor_album where role in (2,4,5)
union
select contributor from albums
) ca on ca.contributor = c.id
order by c.namesort
The "union select contributor from albums" would not be needed if there was a
contributor_album entry for every album, and thus would then be simplified to:
SELECT distinct c.*
FROM contributors c
join contributor_album ca on c.id = ca.contributor and ca.role in (2,4,5)
order by c.namesort
NB:
role 5=album artist, other roles included where wanted. e.g. 2 = composer,
4=band.
This will currently bring back any composer or band, even if they appear only
on one track of an album. But the scanner could be changed to only add these
roles to contributor_album if they were on all songs (same as deciding not to
include track artists in the contributor_albums link table).
Change the query from contributor_album to contributor_track if all artists are
required.
>And the one for the "Various Artists" entry sorted under "V" looks like
>this: (this entry only exists as long as there isn't a collision)
>
>Code:
>--------------------
>
> SELECT album.* FROM albums
> JOIN contributor_album ON contributor_album.album = albums.id
> JOIN contributors ON contributors.id = albums.contributor
> WHERE
> contributor_album.contributor = 7 AND
> contributor_album.role IN (1,6,5)
> GROUP BY albums.id
> ORDER BY albums.titlesort
There doesn't appear to be any need for the join to contributors in this query
(but I guess would be needed for labelling if album artist names were to be
displayed (eg. if choosing to sort by "artist,album", but would then need to
increase columns returned from the query).
Written optimised/clearer:
SELECT albums.*
FROM albums
JOIN contributor_album ON contributor_album.album = albums.id and role IN (
<whatever roles you want to show> )
WHERE
contributor_album.contributor = <chosen artist id>
GROUP BY albums.id
ORDER BY albums.titlesort
_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/ripping
