After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 661903 - banshee album cover art: deleting auto-fetched covers doesn't stick
banshee album cover art: deleting auto-fetched covers doesn't stick
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: Other Extensions
2.2.0
Other Linux
: Normal normal
: ---
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2011-10-16 12:57 UTC by Chow Loong Jin
Modified: 2020-03-17 09:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Chow Loong Jin 2011-10-16 12:57:47 UTC 
Originally reported at:
  https://bugs.launchpad.net/bugs/875594

Right click on an album image.
Properties
Right click on the album image in the properties window
"Delete this cover art".

Cover art is deleted, BUT
As soon as you start playing the track, the album art is re-fetched.

This is annoying.  I haven't seen any cover images that are I'm 100% sure are _wrong_ yet, but there are some that I don't recognize.  I want to be able to null them out, without having to draw up a dummy cover image.

As well as the extra state, I guess this would also need an explicit "check for cover art" action, so I could reverse my decision in future.
Comment 1 André Klapper 2020-03-17 09:28:16 UTC 
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.