GNOME Bugzilla – Bug 647898
Retrieve cover art from files on import prior to downloading
Last modified: 2011-10-23 20:22:15 UTC
Cover art is not being read from the audio files when importing new files. The cover art in files is ignored if you allow Banshee to retrieve cover art from the internet, it will be downloaded right away. Cover art from the files won't be used unless you start to play one of the album tracks if you don't allow Banshee to retrieve the cover art from the internet. This is a waste of resources. The trouble people go through to get the right cover art is discarded and there is no need to start fetching from the internet in the first place. It's also a pita if you are importing multiple albums. You'd have to go by them only by one to play a song just to get the cover art displayed. It would be good if cover art retrieval from files gets a higher priority. Look for cover art in the album folder after that if the files don't contain cover art. Internet could then be used as a last resort.
Are you positive? It's intended that the cover-art fetching process first looks inside the files' metadata, then for a local cover.jpg-ish in the file's folder, then goes out to the internet. You can modify src/Core/Banshee.Services/Banshee.Metadata.Embedded/EmbeddedQueryJob.cs and add a Console.WriteLine or two to ensure it's not being run for your files. Perhaps it is being run but is just failing to work right and get the cover art out? If so, sounds similar to bug #647622.
I'm positive. I have internet disabled because Banshee insists on downloading the cover art (often the incorrect one). If I add a new album I do not get to see cover art unless I play a file first. The issue was present in 1.8.x as well. It might be related to bug #647622 but, unlike that issue, I do get the cover art if I start to play one file of the album. Is cover art retrieval from files by any chance different when importing files compared to playing files?
P.s. this happens for mp3 as well as m4a files.
Are your files on your local hard drive, or on some mount?
Created attachment 186051 [details] [review] debug patch If you could build Banshee from source (http://banshee.fm/download/development/) and apply this patch (patch -p1 < embedded_coverart_debug.patch) and run Banshee again (make run), it will help check what's happening.
Created attachment 186053 [details] Log of successful album import
Created attachment 186054 [details] Log of failed album import
This is so unfair. After applying the patch, the first album I added fetched the cover art from the files like a charm :-S The second album, however, did fail. Attached are two files: - "success.log", containing the log of the first album import with successful album art retrieval - "failed.log", containing the log of the second album import with failed album art retrieval, followed by playing a track to get the art again. I wanted to upload a test mp3 file as well but it is larger then the allowed size for an attachment. Files where (previous version) and are located on a local drive. Let me know if you need any more info.
Age, the Alain Clark album log looks like it did indeed find the artwork - though the img is only 5674 bytes compared to 80k for the successful one. Can you run eog /home/forage/.cache/media-art/album-a8207356f613f873f39d923dee84dd5f.jpg and see if it loads?
In this case it is a small image indeed but note that it was retrieved when starting to play the track. On import, just before the play, no cover art was retrieved. Nothing of such a thing is mentioned in the log, unlike in the log of the successful import of the other album.
If you can `git pull` your git checkout, I just committed a change. Can you try again w/ the failed album, but this time running banshee with --fetch-artwork as well? That is, BANSHEE_DEV_OPTIONS="--fetch-artwork" make run should do the trick. This will tell Banshee to ignore its rate-limiting etc that prevents it from looking up artwork on the same album within a set amount of time.
Sorry to inform you but unfortunately it didn't do the trick. For the record, steps to reproduce: - Enable "Disable features requiring internet access" in the "Preferences" - Import an album not imported before by "Media - Import Media..." Result: - No cover art is displayed for the new album Additional steps: - Play a track of the album Result: - Cover art is displayed Note the "not imported before". When the cover art is retrieved once before, it will get displayed right away if you import the album again.
any news for this report?
From my side not really. The provided patch did not change anything and the issue is still present. I tried writing the tags to the MP3 files in different ways (ID3v2.3, ID3v2.4, UTF-8, UTF-16, ISO8859-1, with tag padding, without tag padding, explicitly setting the image type to front cover) with different applications (easytag, foobar2000, mp3tag) just to see if it would make any change but so far no luck.
Created attachment 190627 [details] Test file Smallest file I could find for testing
*** Bug 658283 has been marked as a duplicate of this bug. ***
The issue remains present in version 2.1.3 of Banshee
My findings for importing folders with "cover.jpg" like cover art: * If I disable features requiring internet access (Edit → Preferences → General), the cover art isn't fetched from disk. * If I don't disable features requiring internet access, then cover art is fetched, while images from disk take precedence over files from the internet. However, I don't want covers to be downloaded at all and I don't want to enable any other features that require internet access.
I can confirm Hernando's findings with some additions. I embedded a fake cover art file in an MP3 file. It will read the cover art from the file but only when the option "Disable features requiring internet access" is UNCHECKED and the extension "Cover Art Fetching" is CHECKED. If it is any other way then nothing is done with the locally present images. Both these options should not have any influence on the reading of the embedded cover art or, as in Hernando's case, the separate image file, but they have. This does, however, contradict my earlier statement. At the time of reporting I was convinced that it was ignoring the embedded coverart completely, downloading all. I'm sure it was the situation at the time but I can't reproduce it as fast as I would like. Maybe it was the case for just a selection of the files. Once the situation described above is fixed I'll perform a more extensive test.
Created attachment 196237 [details] [review] Attempt to fetch coverart without having an internet connection Here's a patch fixing the issue. Any attempt to fetch coverart was prevented when no internet connection was available. Embedded and Filesystem coverart jobs where therefore ignored. Instead, all coverart jobs requiring internet access (LastFM, etc,) should have, and have, an internet check on their own. Note that, due to a different issue, it might appear that the issue has not been fixed with this patch when you add new albums to the library. Run Banshee with --fetch-artwork once after applying the patch as a workaround. As a bonus it will also fetch the (local) coverart of all files present in your library ;-) I'll file a different issue for the other problem because it's not really related.
I'm sorry but I'm kind of a newb.. how can I aplly this patch? I only see text.. Sorry to take up your time.. Thanks in advance, Alejandro Buenos Aires Argentina
(In reply to comment #21) > I'm sorry but I'm kind of a newb.. how can I aplly this patch? I only see > text.. > You'd have to get the Banshee source and compile it yourself. See comment 5 for an explanation, though instead of applying "embedded_coverart_debug.patch" you'd apply "fetch_without_inet.patch" (right-click the patch below and "Save Link As...")
Created attachment 198526 [details] [review] Attempt to fetch coverart without having an internet connection Identical but properly formatted patch
Comment on attachment 198526 [details] [review] Attempt to fetch coverart without having an internet connection Thanks for the patch, good catch ! I split it in two commits, as the change in LastFMQueryJob is good but not directly related to the bug.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.