Bug 134043 - album covers are deleted
Summary: album covers are deleted
Alias: None
Product: amarok
Classification: Unclassified
Component: general (show other bugs)
Version: 1.4.3
Platform: Ubuntu Packages Linux
: NOR normal with 41 votes (vote)
Target Milestone: ---
Assignee: Amarok Developers
Depends on:
Reported: 2006-09-14 02:33 UTC by Janne Vänttinen
Modified: 2006-12-28 17:47 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Janne Vänttinen 2006-09-14 02:33:11 UTC
Version:           1.4.3 (using KDE KDE 3.5.4)
Installed from:    Ubuntu Packages
OS:                Linux

After upgrading to 1.4.3 Amarok sometimes deletes album covers from the filesystem. This has occured at least
- when new cover has been added to collection folder and the collection is updated
- when setting a cover with "set custom cover" -selection
but it doesn't happen every time. File name of the cover may have something to do with this, since this tends to happen again and again to some particular cover images. I have no clue how this could be reliably reproduced, but it happens frequently enough that it should be noticeable.
Comment 1 Clive Messer 2006-10-04 10:23:33 UTC
Me too! Every time I set custom cover to be a cover.jpg in the music folder, Amarok deletes it. Not the desired behaviour.
Comment 2 Angelo Babudro 2006-10-28 00:36:07 UTC
I have noticed the same behaviour for some time, too.  It took me until today to realise it was Amarok doing the erasing and I did some experimenting as soon as I caught on.

Some observations that might be helpful:

- it deletes cover.jpg every time I "set custom cover" -- whether I am setting the cover to "cover.jpg" or or other file like "cover.png" doesn't matter, either way it deletes cover.jpg (and only cover.jpg -- cover.png was never erased).

-- I tried turning off all my permissions on cover.jpg (chmod 000), hoping this would be a simple way to prevent the erasure.  It did not.

-- I tried setting the cover from the playlist and also from within the track editor.  Both ways it erases the file.

-- At first I set the cover from Amazon, but it did not display in the top-left of the playlist album area (only in the artist-albums area below it).  So I downloaded the cover from Amazon and used the "set custom cover" feature hoping it would make it display properly.  That's when it erased the cover.jpg file and still did not display at the top-left (but did still displayed lower down).  I unset the cover and re-set it many times; each time it erased cover.jpg and never would display the album graphic at the top-left.  Maybe this is a clue?

-- It erases cover.jpg whether or not the album is playing, whether or not anything is playing or the player is stopped.

-- I renamed the file to "cover2.jpg", did "Set custom cover", and it did _not_ erase it.  Then I renamed it back to "cover.jpg", "Set custom cover", and *poof* it erased it again.

I access my audio via NFS, in case that's any help in debugging.
Comment 3 Angelo Babudro 2006-10-28 03:42:18 UTC
More details to add to my points above:

I just added an album and did not find the cover on the Amazon lookup, so I cancelled it without setting a cover, got a copy of the cover art elsewhere, Set Custom Cover to the "cover.jpg" file and it set the graphic properly on the top-left but still erased the cover.jpg file.

Note that the graphic appeared in the top-left of the playlist window before it erased the file, so it must read the cover.jpg file first before deleting it.
Comment 4 simon 2006-10-29 12:23:51 UTC
Just happened here too.  
I searched the cover and saved it in the corresponding album folder. 
The next step was to set custom cover in Amarok. And while it's shown fine in Amarok now the file has been moved/deleted from my folder. 
I respect it if amarok makes a copy in it's own folder and stuff - but it should never move/delete files not downloaded by Amarok.
Comment 5 Jo Schulze 2006-10-29 14:43:26 UTC
I can confirm the mentioned destructive behavior.

However, I can't give a 100% hint about how to reproduce.

Here is how I 1st noticed deletion of custom covers:

1) Restart amarok. Under "Context", collection statistics are shown, followed by "Your Newest" and "Favorite Albums"
2) Copy an image file into the same directory where the audio files of a "Your Newest Albums" are stored.
3) Right-click the entry from "Your Newest Albums", select "Set Custom Cover", choose the image file.

In my case, the image file was gone afterwards. But this doesn't always happens, it seems to be related to the old data stored in the DB for this album: if the entry already has a custom cover and the new custom cover has the same filename, the image file stays. If the new custom cover is from a different file, the new image will sometimes be deleted.

Unsetting a custom cover also sometimes deletes the image file (instead of resetting the thumbnail to the empty CD case icon (as the warning "Are you sure you want to remove this cover from the Collection?" implies).

When trying to reproduce with 2 or more different image files, I noticed that the whole thing doesn't work as expected: sometimes the covers are set correctly, sometimes the old thumbnail is shown, sometimes a "broken image" icon is displayed, I even had the ID3 "Artists" being displayed as "Unknown" after changing the cover (the ID3 tag wasn't changed, only a display issue).
This makes bug reproduction even harder, because I never know wether the displayed data is correct.
Comment 6 Wolfgang Sailer 2006-11-19 15:28:49 UTC
I can also confirm this behaviour. Sometimes I scan in covers or download covers that the "fetch from amazon" function gets wrong. Sometimes those covers get deleted. Amarok 1.4.3 on KDE 3.5.5 Kubuntu 6.10
Comment 7 Wolfgang Sailer 2006-11-19 15:30:00 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Marcel 2006-12-14 17:42:51 UTC
This bug is still there...please, look into this!

It's freaking me out, seriously...

I'll switch to another player for now, it's just too annoying.

I really hope this gets fixed soon...

(Amarok 1.4.4, Kubuntu Edgy DEBs from kubuntu.org)
Comment 9 Benjamín Valero Espinosa 2006-12-17 13:41:23 UTC
It is not a bug of SQLite, it also happens with MySQL database. amaroK should only delete covers from the cache.
Comment 10 Benjamín Valero Espinosa 2006-12-17 14:47:02 UTC
I think I have found an easy way to reproduce that but 100%:

* In context menu, click "Set custom cover" and set another one. The one installed before is deleted.

Anyway, I have been trying for days and I have got a strange conclusion. Ubuntu Edgy has the version 1.4.3 installed and has this bug. I have proved the version 1.4.4 of the Kubuntu updates and the bug is still here. But I have tried the version 1.4.3 (yes, the same that is in Edgy) but from the Dapper-backports repository... and I haven't been able to reproduce this bug.

Does anybody know if this bug happens in some other distro besides (K)Ubuntu?
Comment 11 Clive Messer 2006-12-17 15:16:25 UTC
Bug is still present in Fedora extras package - amarok-1.4.4-2.fc6
Comment 12 Angelo Babudro 2006-12-20 02:28:32 UTC
In response to Benjamin Esponosa's question, "Does anybody know if this bug happens in some other distro besides (K)Ubuntu?"

Yes.  I'm using Gentoo and can confirm it exists in 1.4.3 and 1.4.4 built from source for AMD64 architecture.
Comment 13 Benjamín Valero Espinosa 2006-12-20 07:49:03 UTC
Well, if the same version (1.4.3) compiled Ubuntu Dapper works wrong in Ubuntu Edgy with the same version of KDE (3.5.5), I suppose that the bug should be in the *little* changes of code of amaroK from 1.4.3-0ubuntu8 to 1.4.3.-0ubuntu10. I think this is all I can help at this moment.

Perhaps in other distros can be also useful to check since which version this bug appears to bound the search. Anyway I tell it again, this bug is inacceptable, I have more images inside the same folder of a CD (the back-cover, for example) beside the cover, and I don't want to lose them :(
Comment 14 Benjamín Valero Espinosa 2006-12-20 23:30:56 UTC
I have downloaded the original source of the version 1.4.3, compiled it in Edgy and the bug appears. Summarizing (in Ubuntu):
* 1.4.3 compiled in Edgy -> bug
* 1.4.3-0ubuntu8 from Dapper-Backports repository -> NO bug!!
* 1.4.3-0ubuntu10 from Kubuntu Edgy repository -> bug
* 1.4.4 compiled in Edgy -> bug

Since I can't at this moment compile in Dapper, I dare to throw a hypothesis: perhaps the bug is not in amaroK but in the new KDE libraries. It seems possible but I don't understand where and why.
Comment 15 Alexandre Oliveira 2006-12-27 22:27:41 UTC
No matter how hard I try, I can't reproduce this.
Comment 16 Benjamín Valero Espinosa 2006-12-27 23:19:57 UTC
Sorry Alexandre, would you be so kind of telling which distro, kdelibs and amaroK version are you using? I would really like to agree with you :)
Comment 17 Alexandre Oliveira 2006-12-28 01:42:37 UTC
Amarok SVN, gentoo, kde-libs 3.5.5
Comment 18 richlv 2006-12-28 10:27:35 UTC
ouch. method described in comment 10 works perfectly. good thing i had a copy this time...
i had observed this for quite some time, but never managed to catch the moment when a cover disappeared as i noticed that only some time later.

slacklware-11.0, svn amarok and kde 3.5.4.

i can recompile amarok with whatever patches needed to pinpoint the cause.
Comment 19 Mark Kretschmann 2006-12-28 11:17:53 UTC
I absolutely cannot reproduce this. Tried the method described in comment 10. Images are still there.
Comment 20 Mark Kretschmann 2006-12-28 12:33:24 UTC
Ok, I figured out what's going on. It's actually supposed to be a feature:

See BUG 118069

The commit that enabled this was:

r575884 | seb | 2006-08-22 14:17:47 +0200 (Tue, 22 Aug 2006) | 3 lines
Changed paths:
   M /trunk/extragear/multimedia/amarok/src/collectiondb.cpp

Delete artwork off the filesystem as well as the cache if it is requested
CCBBUG: 118069

Comment 21 Mark Kretschmann 2006-12-28 12:44:47 UTC
SVN commit 617196 by markey:

Don't physically delete custom cover images from the filesystem. Apparently users really don't like this, although it was originally meant as a feature.

BUG: 134043
CCBUG: 118069

 M  +1 -1      collectiondb.cpp  

--- trunk/extragear/multimedia/amarok/src/collectiondb.cpp #617195:617196
@@ -2295,7 +2295,7 @@
     QString hardImage = findDirectoryImage( artist, album );
     debug() << "hardImage: " << hardImage << endl;
-    if( !hardImage.isEmpty() && QFile::remove( hardImage ) )
+    if( !hardImage.isEmpty() )
         int id = MountPointManager::instance()->getIdForUrl( hardImage );
         QString rpath = MountPointManager::instance()->getRelativePath( id, hardImage );
Comment 22 Clive Messer 2006-12-28 15:49:04 UTC
Thankyou, Mark. (I'll be a lot happier without that 'feature'! ;-)
Comment 23 Wolfgang Sailer 2006-12-28 17:47:24 UTC
as to comment #21: confirmed: I *REALLY* don't like this.