| Summary: | Embedded id3v2 cover art not displayed | ||
|---|---|---|---|
| Product: | [Applications] amarok | Reporter: | Syam <get.sonic> |
| Component: | Collections/Local | Assignee: | Amarok Developers <amarok-bugs-dist> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | bernardo, carlos_tocha, connelhooley, echukwuogor, ecroy, eqisow, hochglanz, jammen, karthik.periagaram, kde-bugs, kirsch.andreas, kleinerwolf, michael.seiwert, mitchell, mmk+bugs, rdieter, rktspm, stuffcorpse, thebobcampbell, tobias, tommann.home, wesleyhg |
| Priority: | NOR | ||
| Version: | 2.3-GIT | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Same image repeated for several different albums | ||
|
Description
Syam
2008-11-29 04:14:02 UTC
Could you please make one of these files accessible to us, so that we can reproduce the problem? @Mark: reading embedded artwork from files is not implemented in A2, so it's not a bug, as much as a missing feature. Oh ok, thanks for clearing that up. @Seb: That's one missing killer feature :-( But I'm confused since your own blog (dated June 2008) says Amarok 2 supports cover art (http://www.sebruiz.net/337). Oops.. sorry.. I didn't read the blog carefully enough. It does say that embedded artwork is not supported. My bad! *** Bug 183751 has been marked as a duplicate of this bug. *** Will this make it to any Amarok release? I'd like to have my MP3 metadata embedded in the files themselves (and not separate image files). That way, I get better interoperability between applications (and even cell phone media players can display the embedded artwork). Please see the re-worked digiKam first-run screen for a similar use-case: http://www.flickr.com/photos/digikam/3489923047/ @Syam: yes, we will bring it back but it is not on the roadmap yet. You'll be the first to know. @Seb: Thanks *** Bug 195728 has been marked as a duplicate of this bug. *** Any news on this? As a user, I've taken to using the album.jpg approach (Most music players will use a jpeg image named album.jpg in the directory containing the contents of the album. This works fine in Amarok 2. A quick way to do this is to fire up kid3, select a song, choose the Picture field, Edit and Export the image as album.jpg in the directory containing the song) but it will be a tedious solution to the problem if the library contains thousands of songs. Perhaps someone can provide a script that will recursively comb a music directory, read the embedded image in the tags and export them as album.jpg in the respective directory? That will be a useful stopgap till this feature is implemented in Amarok. (In reply to comment #12) That'd work only if you have strictly 'one album, one directory' structure. My collection has lots of single tracks and I don't group them in separate directories - they can be grouped by album in Amarok anyway. So I can't use this method. :-( I also submitted this bug (and had it rolled in to here) and, like Syam, I have my music organized in such a way that using the album.jpg trick wouldn't work. Each artist has a directory, but no subdirectories per album. *** Bug 96667 has been marked as a duplicate of this bug. *** Setting as a wish, as this is a missing feature, not a bug. *** Bug 207402 has been marked as a duplicate of this bug. *** *** Bug 207402 has been marked as a duplicate of this bug. *** Since Myriam fails reading comprehension and somehow thinks this bug solves 207402, let me just paste the other here and be done: Amarok should support (1) attempting to read [album art and lyrics] tags before fetching lyrics/album art from the net and (2) writing these tags instead of storing it in the local database. For (1), reading from these tags would make switching TO Amarok easier for a large number of people. For (2), writing these tags would (a) make losing your database less painful and (b) make using various applications to access the same library more hassle free. Please watch your language, Justin. We have to process a huge amount of reports every day, and sometimes mistakes happen. Just humans, you see :) That's true, and I apologize for the rude comment. However it was closed as a duplicate once. I made my case and re-opened it, several people agreed, and it was closed as a duplicate again, with commentary. Hardly a 'mistake.' At any rate, you guys can do what you want with it. Showing embedded cover artwork would be a very great feature of amarok! All my (mp3) files are added with covers and I'd very like to see these covers in Amarok (again). This problem seems to have already been solved by the bangarang devs. For those not in the know, bangarang is a sort of media player/manager for KDE4 nearing its first release. Here's their page on kde-apps.org: http://www.kde-apps.org/content/show.php/Bangarang?content=113305 Pertinent to this wishlist, the current version of bangarang reads album artwork from mp3 files. I am not really adept at coding, but it might be easy to implement this in amarok by reusing the code from bangarang. is it so hard to add this feature to amarok, again?! (In reply to comment #24) > is it so hard to add this feature to amarok, again?! Well, the developers have only two hands each and the day only as 24 hours (not to mention they work for free). You are welcome to give a hand :) Good news, everyone :) Amarok 2.3 will finally have this feature: commit a0c4a6c706d6f4f6cf22740bfa4aec768a7c4b87 Author: ecroy <ecroy@gmx.net> Date: Fri Feb 26 01:41:55 2010 +0100 Add embedded cover art support Wow! This has to be the best Amarok/KDE news I've heard in a while. Thanks devs, and thanks to Mark for the heads up. YES!!! Thanks so much for this! :) Thank you for this good information.go amarok go :) This feature as implemented has serious issues and should never have been merged into 2.3, which is deep in feature freeze. It is going to be reverted. Look for it in 2.3.1. I'm disappointed - it's not in 2.3.1 :( Can anyone specify a Target Version for this feature? There was some controversy about the way my patch implemented this feature - unfortunately I did not find enough time to do it differently because the suggested ways seemed far more intrusive to me. Hopefully somebody more familiar with the codebase picks up on this, but currently nobody seems to be working on it :( *** Bug 241045 has been marked as a duplicate of this bug. *** *** Bug 244266 has been marked as a duplicate of this bug. *** *** Bug 244434 has been marked as a duplicate of this bug. *** FYI, I've implemented this feature for the upcoming 2.3.2. It currently works only for MP3s, as I don't have any other types of files with embedded cover art with which to test. I haven't closed this because there is still some work to do. The changes invalidate the cached covers, including downloaded covers. One of the other developers is implementing a fallback system to get files to the correct new places if they don't exist there already. @Jeff Mitchell, thank you, it works :) Sure. To give a shout-out where it's due, Ralf Engels is doing some nice work now cleaning the whole system up. (That's also why I'm keeping this as opened, to help remind me to keep tabs on that.) Thank you Jeff Mitchell, Ralf Engels and all the other devs/testers working on this. Thanks a lot.. I just installed Amarok 2.3.2 (from kde-testing repo of Fedora KDE SIG), and album art images are mostly displayed wrong. A couple of images are wrongly used for a large number of albums (see the attached screenshot). Created attachment 52385 [details]
Same image repeated for several different albums
Please open a new bug for this. |