ops sorry, I meant it would be great if I could just turn the prompting off.

I don't think adding such an option is a good idea.  If it's annoying, we need to find a way to make it not annoying.

How many codecs is it asking you to install?  Is it asking you multiple times for each codec (it shouldn't be)?  Is there a reason you're not just installing the codecs?  Is it asking you to install video codecs (it shouldn't be), or just audio?

it prompted me 11 times so far, i doubt it's asking me for the same codec, i don't want to install the codec - some of he files are .rm and don't even play once i've installed the codecs.

"Is it asking you to install video codecs (it shouldn't be" I was asked to install mpeg 4 video decoder.

I get prompted twice times, every time I start Rhythmbox, to install codecs. But the dialog that pops up does not state which codec it wants to install, or even the file that it's trying to access that it can't parse. When I tell it to go ahead and Do What I Want, it always comes up empty.

I am only prompted once for each type of file, however. The two messages that pop up are associated with these log messages:

libWildMidi(WM_ParseNewMidi:3548): ERROR File corrupt (Expected EOT)
libWildMidi(WildMidi_Init:3707): ERROR Library not Initialized
Rhythmbox-Message: Missing plugin: gstreamer|0.10|rhythmbox-metadata|audio/midi decoder|decoder-audio/midi

  The MIDI one is interesting... I have MIDI files that *do* play in rhythmbox... 
  (only once, but that's a GSreamer bug).

Rhythmbox-Message: Missing plugin: gstreamer|0.10|rhythmbox-metadata|application/x-bzip decoder|decoder-application/x-bzip

  Maybe this mime type (and application/x-gzip if it exists) should also be added 
  to the blacklist?

Anyway, I think the way to make this feature less annoying is:

 * Always do a codec search when a missing codec is needed
 * If the search worked, prompt the user to install the codec (say what the file is, and what the codec that will be installed is)
   - If possible, just go ahead and install it without prompting.
     Presumably this will be possible with PackageKit some day...
 * If the search failed, put an entry in the 'Import Errors' source

(In reply to comment #4)
<snip>
> libWildMidi(WM_ParseNewMidi:3548): ERROR File corrupt (Expected EOT)
> libWildMidi(WildMidi_Init:3707): ERROR Library not Initialized
> Rhythmbox-Message: Missing plugin: gstreamer|0.10|rhythmbox-metadata|audio/midi
> decoder|decoder-audio/midi
> 
>   The MIDI one is interesting... I have MIDI files that *do* play in
> rhythmbox... 
>   (only once, but that's a GSreamer bug).

That error message is completely due to that same GStreamer bug. Upgrade your gst-plugins-bad installation, and that'll be sorted.

Well, obviously, RB should not search codecs for every type of file. Almost all users have text files, images (covers), archives and diverse data in their Music folders. There must be a mechanism so that:
1) non-music files don't prompt a codec dialog (background search?)
2) files that were prompted once for codec installation never trigger this again (except when clicked manually)
3) RB groups codecs so that only one dialog is shown (list with toggles)
4) the name of the file and of the codec is shown in the prompt

This is IMHO how the perfect solution would look like. Sure it can't be achieved immediately, but with PackageKit it should be doable soon.

At least point 1 and 2 should find a workaround quickly, it's highly annoying...

*** Bug 568699 has been marked as a duplicate of this bug. ***

Version 0.12 is steal affected. Are there any progress on this bug?

I've seen this (RB 0.11.6/Ubuntu Intrepid and 0.12/Ubuntu Jaunty) while there were broken MP3 files in my library. RB then always tried to install a codec for "ID3 demuxer". Additionally the codec search popup appeared because of some RTF files in my music library. I removed those files because I do not need them, but this is not a good solution - in principal it absolutely legal to have non music files in the music library and a music player (especially my favorite one - Rhythmbox :) should be able to handle this.

.. just a comment to vote for this bug.

Created attachment 133634 [details]
Broken MP3 that triggers a codec install for application/x-id3

A broken MP3 file that triggers the codec installer for decoder-application/x-id3.  Taken from Ubuntu bug:
https://bugs.launchpad.net/rhythmbox/+bug/343707

That's a GStreamer bug (that seems to have been fixed - for me it just reports an error).  If the id3 demuxer wasn't installed for some reason, we'd want to install it.

Jonathan, what version of GStreamer are you using?  This is testing with GStreamer 0.10.22 and Rhythmbox 0.12.0.  I have the ID3 decoder installed in /usr/lib/gstreamer-0.10/libgstid3demux.so and other MP3 files using ID3 work.

I use a fairly up to date git version of gstreamer.

What output do you get from 'gst-launch-0.10 -tm filesrc location=broken.mp3 ! decodebin2 ! fakesink silent=true'?

Created attachment 133720 [details]
Output of gst-launch-0.10 -tm filesrc location=broken.mp3 ! decodebin2 ! fakesink silent=true 2>&1 > broken.log

My testing was a little bit stupid.  It's not actually fixed in decodebin, and I somehow thought we'd switched to decodebin2 for metadata reading.  Switching to decodebin2 will fix this, and I plan to do this pretty soon anyway.

I made the following change and it appears to work perfectly.  Is any more work required for this change?

diff --git a/metadata/rb-metadata-gst.c b/metadata/rb-metadata-gst.c
index 255c035..122fb52 100644
--- a/metadata/rb-metadata-gst.c
+++ b/metadata/rb-metadata-gst.c
@@ -1047,7 +1047,7 @@ rb_metadata_load (RBMetaData *md,
        }
        gst_bin_add (GST_BIN (pipeline), urisrc);
 
-       decodebin = make_pipeline_element (pipeline, "decodebin", error);
+       decodebin = make_pipeline_element (pipeline, "decodebin2", error);
        md->priv->sink = make_pipeline_element (pipeline, "fakesink", error);
        if (!(urisrc && decodebin && md->priv->sink)) {
                rb_debug ("missing an element, sadly");

If all we wanted to do was switch to decodebin2 and keep the rest of the process as-is, then that patch would be all we'd need.

I'm part-way through rewriting the metadata code to make use of features added in decodebin2.  This will fix a number of long-standing bugs (ape tags, mp4 podcasts, one part of this bug, ..), and I hope to finish it off in the next month or two.

*** Bug 584152 has been marked as a duplicate of this bug. ***

*** Bug 584151 has been marked as a duplicate of this bug. ***

*** Bug 584150 has been marked as a duplicate of this bug. ***

Hey, look at that, I sort of followed through on something I said in a bugzilla comment.

With my recent set of metadata code changes, we only run the codec installer for audio-only files.  That's about as fixed as this is going to get.

Great! Can we also expect that RB will stop prompting several times for the same missing codec? What was especially a problem is that if you could't find a codec or refused to install it, RB was nagging you at every start.

Thanks for tackling that - I hope this kind of fix will prevent Ubuntu from switching to Banshee by default as they seem to consider.

It doesn't remember which codecs you have not installed across restarts - without a way to distinguish 'not now' from 'not ever' that seems like spending a lot of effort in the wrong direction.  Why would you want to keep audio files in your library that you can't play?

(In reply to comment #22)
> Thanks for tackling that - I hope this kind of fix will prevent Ubuntu from
> switching to Banshee by default as they seem to consider.

From what I've seen of how this process works, improvements to rhythmbox don't factor into it.  Anyway, if it didn't happen in this release, it would in the next.

I've not tested this kind of situation, but say your distribution does not provide a codec for an obscure audio format (often you need to enable third party repos, and that can be complex), or you don't want to install support for Microsoft's formats (e.g. corporate environment).

That would mean you have to remove the file from your library's folder, which is something many users won't do because that requires you to find that file (using --debug?) in hierarchies that can be really messy, and most users are lazy when they don't really understand what happens. Another problem is that your library's directory is often shared with other uses, e.g. I'm syncing all files with my portable audio player. What if it supports DRMed WMA, which RB won't read?

Maybe I'm asking for too much work here, but isn't it possible to add a flag in the DB saying: skip automatic codec check for this file? Or for this codec? If one day you change your mind or a new codec is released, you can still ask for the codec when the user tries to play the file.

What do you think of my UI suggestions in comment #4? :)

I think the individual prompting for each codec that needs attention is one of the things that make this bug so annoying. The machine is unusable for the period that Rhythmbox is starting up, because the popups grab focus from whatever the user happens to be doing in the other window (I myself have had it grab focus while I'm in the middle of typing a password several times.)

The ideal UI should prompt the user once, displaying a list of all of the media codecs it does not have. To the right of each missing codec, there should be a radio button or a check box which gives the user the option to search for codecs, or to ignore these files. Then the user can authorize the search for codecs with a single click, rather than being required to give individual attention to flac, mp3, or any other obscure formats that may be present. 

Also, I think the decision to use pop-ups that grab focus from any other window is a generally poor usability choice, and a notification in the corner of the screen should suffice, so long as the sidebar in Rhythmbox's main window prominently displays a list of the missing codecs as described above. The pop-ups drastically increase the amount of user interaction required to import a library with even a modest amount of non-default codecs, and on a slower internet connection could extend the time required considerably.

*** Bug 589175 has been marked as a duplicate of this bug. ***

*** Bug 596324 has been marked as a duplicate of this bug. ***

Sorry to reopen that one, but I'm still getting the problem with RB 0.12.5, because of an invalid MP3 file triggering search for an ID3 demultiplexer (see full log attached):

(12:18:29) [0x93ef8a8] [rb_metadata_handle_missing_plugin_message] rb-metadata-gst.c:534: got missing-plugin message from decodebin: gstreamer|0.10|rhythmbox-metadata|Démultiplexeur Étiquette ID3|decoder-application/x-id3
(12:18:29) [0x93ef8a8] [rb_metadata_gst_get_missing_plugin_type] rb-metadata-gst-common.c:244: missing plugin is a container demuxer
(12:18:29) [0x93ef8a8] [rb_metadata_bus_handler] rb-metadata-gst.c:580: got error message from decodebin
(12:18:29) [0x93ef8a8] [rb_metadata_bus_handler] rb-metadata-gst.c:596: caught error: Un greffon Démultiplexeur Étiquette ID3 est requis pour lire ce flux, mais il n'est pas installé. 
(12:18:29) [0x93ef8a8] [rb_metadata_load] rb-metadata-gst.c:792: failed to go to PAUSED for file:///home/milan/Baladeur/Keith%20Jarrett/At%20the%20Blue%20Note/CD1/01.In%20Your%20Own%20Sweet%20Way.mp3


I had already identified this file as leading to this bug. It's a very short corrupt MP3 file that I uploaded here:
http://launchpadlibrarian.net/26058714/01.In%20Your%20Own%20Sweet%20Way.mp3

Maybe that's still a bug in GStreamer? The ID3 demultiplexer is already installed, and the codec search can't provide one. I'm using gst-plugins-good 0.10.16 and gst-plugins-bad 0.10.13

That is definitely a GStreamer bug.  It shouldn't be reporting things that are already installed as being missing.  This doesn't happen with decodebin2, only decodebin, so a fix is pretty unlikely.  Rhythmbox will sooner or later switch to decodebin2 for metadata.

Ah, okay, I thought RB had switched to decodebin2 already. So let's wait.

*** Bug 608210 has been marked as a duplicate of this bug. ***