Bug 134043

Me too! Every time I set custom cover to be a cover.jpg in the music folder, Amarok deletes it. Not the desired behaviour.

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.

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.

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.

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.

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

*** This bug has been confirmed by popular vote. ***

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)

It is not a bug of SQLite, it also happens with MySQL database. amaroK should only delete covers from the cache.

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?

Bug is still present in Fedora extras package - amarok-1.4.4-2.fc6

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.

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 :(

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.

No matter how hard I try, I can't reproduce this.

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 :)

Amarok SVN, gentoo, kde-libs 3.5.5

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.

I absolutely cannot reproduce this. Tried the method described in comment 10. Images are still there.

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

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 );

Thankyou, Mark. (I'll be a lot happier without that 'feature'! ;-)

as to comment #21: confirmed: I *REALLY* don't like this.