<span style="color: rgb(0, 0, 0);">Hi everyone,</span><br style="color: rgb(0, 0, 0);"><br style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 0);">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! ;)

</span><br style="color: rgb(0, 0, 0);"><br style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 0);">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?

</span><br style="color: rgb(0, 0, 0);"><br>----<br><br style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 0);">Firstly, about the bug I'm looking at (<a href="https://bugs.kde.org/show_bug.cgi?id=148586">https://bugs.kde.org/show_bug.cgi?id=148586

</a>). 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".

<br style="color: rgb(0, 0, 0);"></span><br>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. 

<br><br>To fix it fully I could have a look at the following:<br>- Change a blank artist to "Various Artists" when reading from CoverFetcher (Easy but hacky)<br>- 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)

<br>- Using inheritance create another version of CoverFetcher without an artist specified in the constructor especially for the purpose of compilations. (unnecessarily complex?)<br>- Completely remove artist and album information from the CoverFetcher constructor and provide this using parameters instead (very different from current implementation)

<br><br>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?<br>What do you reckon?<br><br>----<br><br>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: 

<a href="https://bugs.kde.org/show_bug.cgi?id=125689">https://bugs.kde.org/show_bug.cgi?id=125689</a> 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.

<br><br>----<br><br>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.<br><br>Thanks for your time and a great program!<br>- 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?

<br>