Cover Manager/Various Artist Issue Bugfixing

[J A]

Hi everyone,

Firstly, I feel I have to keep to form and say how good I think Amarok is.
If I had to pick an OSS project to tag as a "killer app" then this would be
it. If I didn't think it was then I wouldn't be here asking about this
stuff. Besides, It's the way most people start their emails on this list and
who am I to break tradition! ;)

Anyway, over the summer while I had some free time I'd been looking at a
side project and decided to have a look at Amarok as I thought I could put
my effort into fixing a few of my pet annoyances. Firstly, I have been
looking at fixing a bug I found within the Cover Manager for 1.4.x and have
realised that fixing it would require a little refactoring to fix properly.
This led on to me thinking about Amarok 2 and some ideas to improve and
perhaps have a small redesign of the way that Amarok deals with Various
Artists and compilations. I'm not sure if anything like this is planned when
looking at the new database schema?

----

Firstly, about the bug I'm looking at (
https://bugs.kde.org/show_bug.cgi?id=148586).
To summarise, I discovered that Cover Manager has problems updating and
removing the covers for albums which are either; by Various Artists or have
the same name as another album by another artist (so Amarok believes they
are the same album yet I told it not to group them under Various Artists).

Images fetched from Amazon are stored as a file named using the md5 hash of
the artist and name of the album. However, apparently in non-US (and
presumably non-UK) Amazon locales searching for "Various Artists" as an
artist is problematic. Therefore fetchCover() will treat the artist field as
blank when creating a md5 hash and a CoverFetcher object so the default
search string just contains the album name if the database has the album
tagged as a compilation ("sampler" in the DB).

The problem occurs when removeCover() does not check to see if the album is
a compilation and just uses "Various Artists" as the artist name. So it
generates a different hash and filename to fetchCover() so unsurprisingly
the database isn't correctly updated nor is the file deleted.

Now this is a pretty simple and getting the correct file and DB behaviour is
a simple copying of the check used by fetchCover(). Unfortunately it's not
quite there because the message sent to the GUI to update the covers
[loadCover()] uses the data directly from the CoverFetcher object so the
artist is returned blank when the GUI should be looking for "Various
Artists".

This is where I wanted to ask at the best approach to fixing this properly
(being new to QT and the Amarok project). The simple fix is really easy with
the annoyance that the Cover Manager covers won't update unless you close
and reopen it.

To fix it fully I could have a look at the following:
- Change a blank artist to "Various Artists" when reading from CoverFetcher
(Easy but hacky)
- Enclose the "Various Artists" to "" conversion within CoverFetcher and
make simply not include artist information in the search if it is "Various
Artists" (Makes CoverFetcher have non-obvious functionality)
- Using inheritance create another version of CoverFetcher without an artist
specified in the constructor especially for the purpose of compilations.
(unnecessarily complex?)
- Completely remove artist and album information from the CoverFetcher
constructor and provide this using parameters instead (very different from
current implementation)

Lastly, is it worth fixing properly at all given that I seem to be the only
person who has noticed this and Amarok 1.4.x is going to be superseded by
the shiny new 2.0?
What do you reckon?

----

Another thing I was going to look at was the fact that in the collection
view, it only groups by Various Artists when in the default "Artist > Album"
view but not (as I'd like) in the "Genre > Artist > Album" view. It seems
that this has been reported before and had a patch made but not made it into
the current tree: https://bugs.kde.org/show_bug.cgi?id=125689
Was it decided that the current/existing functionality was as intended?

Over all, it seems that Amarok has one of the most flexible approaches to
grouping tracks from compilations but also that it is presumably not very
widely used (since I seem to have filed the only report on the first bug
above*) and often a source of confusion on the forums. It would be great if
this could be polished for Amarok 2. My thoughts are that it would be great
if the cover manager and the handling of Various Artists could be merged
together to make a simplified Album Manager screen (or similar) and the
connection between "Various Artists" (GUI), "compilations" (code) and
"sampler" (Database) could be cleared up while refactoring is going on to
make Amarok 2.

----

I realise this email has become a bit long, sorry about that, but I thought
it would probably be better than putting my questions into Bugzilla.

Thanks for your time and a great program!
- John



* I quickly asked around on #amarok. Granted not many people were around but
no-one else seemed to have the problem. Originally it was suggested it was a
database problem but after finding the above perhaps this is because non of
them have messed around with compilation grouping using the right-click menu
"Show as Various Artists" feature?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20070830/ada364aa/attachment.html>