Description of problem: Amarok has a feature which tries to search for an MP3 plugin using kpackagekit or the GNOME equivalent, if no MP3 plugin is installed. However, this fails to find the appropriate plugin(s), even though the appropriate repository is enabled on my system. Version-Release number of selected component (if applicable): amarok-2.4.0-2.fc15.x86_64 How reproducible: Haven't tried Steps to Reproduce: 1. Play mp3 stream 2. Accept offer to search for mp3 plugin Actual results: It says searching for whatprovides, launches kpackagekit, but then a message appears saying that no plugin was found. Expected results: Plugin found Additional info: After installing the appropriate plugins with kpackagekit by hand, and restarting amarok, the mp3 stream plays. So the plugins are available.
This is more likely a (k)packagekit issue. To be clear, which "appropriate plugins" did you install exactly?
I covered all my bases by installing gstreamer-plugins-{ugly,bad}, and xine-lib-extras-freeworld - all from rpmfusion I think. That covers both the gstreamer backend and the xine backend.
ok, to be clear, the codec install pieces here only works with gstreamer
One more bit of interesting testing, if you're able, yum install gnome-packagekit yum remove gstreamer-plugins-{ugly,bad} kpackagekit logout/login repeat test will help highlight if the problem lies in kpackagekit or lower (ie, in PackageKit or repo metadata).
Can you provide information on what gstreamer capability Amarok is looking for? It will look something like: gstreamer0.10(decoder-audio/mpeg)(......)
I can confirm this works for me with latest updates, using, https://admin.fedoraproject.org/updates/phonon-backend-gstreamer-4.5.1-1.fc14 in particular.
Still doesn't work for me. (In reply to comment #4) > One more bit of interesting testing, if you're able, > > yum install gnome-packagekit > yum remove gstreamer-plugins-{ugly,bad} kpackagekit > logout/login > repeat test > > will help highlight if the problem lies in kpackagekit or lower (ie, in > PackageKit or repo metadata). Same bug occurs with gnome-packagekit. (In reply to comment #5) > Can you provide information on what gstreamer capability Amarok is looking for? > It will look something like: > > gstreamer0.10(decoder-audio/mpeg)(......) I don't see any mention of that anywhere. (In reply to comment #6) > I can confirm this works for me with latest updates, using, > https://admin.fedoraproject.org/updates/phonon-backend-gstreamer-4.5.1-1.fc14 > in particular. That's Fedora 14, not Fedora 15.
OK, re-assigning to phonon-backend-gstreamer , there still seems to be some mismatch between dependencies that needs to be sorted out.
OK, my f14 box, phonon gives debug output: ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) and gstreamer-plugins-ugly-0.10.16-2.fc14.x86_64 includes the matching Provides: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) good! Now, on f15, amarok/phonon gives output: ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) and for comparison, totem too says the same thing. Now, checking what gstreamer-plugins-ugly-0.10.18-1.fc15.x86_64 Provides: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) does not match what PK looks for, so fail. (1) Seems clear this goes deeper, bouncing over to the gstreamer folks to determine what's going wrong where.
ping, been a month, and automatic mp3 codec install feature is still not working, nor has there been any feedback or comment by it's maintainer(s).
Could it also be a problem in gstreamer-plugins-ugly 0.10.18 not being in sync with Fedora's newer gstreamer* (0.10.35 and 0.10.30)? Has it been reported also to the -ugly packager(s)? [...] F15 x86_64 : confirmed with SoundConverter. It also looks for the extra '(mpegaudioversion=1)', which isn't found. [...] F16 x86_64 : worse as the search dialog does not even open: | Error | | failed to install plugins: <enum | GST_INSTALL_PLUGINS_NOT_FOUND | of type GstInstallPluginsReturn> | | [Close] Terminal output: ** Message: PackageKit: xid = 0 ** Message: PackageKit: Codec nice name: MPEG-1 Layer 3 (MP3) decoder ** Message: PackageKit: ignoring field named parsed ** Message: PackageKit: field is: mpegaudioversion, type: gint ** Message: PackageKit: field is: mpegversion, type: gint ** Message: PackageKit: field is: layer, type: gint ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) ** Message: PackageKit: Did not install codec: Message did not receive a reply (timeout by message bus)
still present on f16 ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) ** Message: PackageKit: Did not install codec: Could not find plugin in any configured software source rpm -q gstreamer PackageKit gstreamer-0.10.35-1.fc16.x86_64 yum install gstreamer-plugins-ugly ... gstreamer-plugins-ugly-0.10.18-3.fc16.x86_64 rpm -q --provides gstreamer-plugins-ugly | grep mp gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)()(64bit) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=1)()(64bit) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=2)()(64bit) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=false)()(64bit) gstreamer0.10(decoder-video/mpeg)(mpegversion=1)(systemstream=true)()(64bit) gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=false)()(64bit) gstreamer0.10(decoder-video/mpeg)(mpegversion=2)(systemstream=true)()(64bit) gstreamer0.10(element-lamemp3enc)()(64bit) gstreamer0.10(element-mp3parse)()(64bit) gstreamer0.10(element-mpeg2dec)()(64bit) gstreamer0.10(element-mpegdemux)()(64bit) gstreamer0.10(element-mpegparse)()(64bit) gstreamer0.10(encoder-audio/mpeg)(mpegversion=1)(layer=2)()(64bit) gstreamer0.10(encoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) Problem being PackageKit was asked to look for: gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) but the closest match is: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) ie, no (mpegaudioversion=1)
Opened upstream bug, https://bugzilla.gnome.org/show_bug.cgi?id=662943
OK, seems the --rpm flag is fedora-specific (upstream closed bug), anyway, here's the analysis I mentioned upstream that's still relevant: After asking tdfischer (of phonon-gstreamer fame) came to the conclusion that gstreamer's gst_missing_plugin_message_get_installer_detail function, and output from gst-inspect --print-plugin-auto-install-info --rpm no longer match. This last worked for me using gstreamer-0.10.31-1.fc14 And started not working as of gstreamer-0.10.34-1.fc15 and retested and confirmed not working too with: gstreamer-0.10.35-1.fc16 In particular, starting with 0.10.34 , when trying to play mp3 audio via gstreamer applications (like totem or phonon-gstreamer), gst_missing_plugin_message_get_installer_detail returns gstreamer0.10(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) but gst-inspect --print-plugin-auto-install-info --rpm /usr/lib64/gstreamer-0.10/libgstmad.so gstreamer0.10(element-mad) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=1) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=2) gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3) note the missing (mpegaudioversion=1) in the latter.
Ping?
Ping? Any news about this issue? Or do you want me to start the non-responsive maintainer process? (This has been open for almost a year without any answer from a GStreamer maintainer, and I've been waiting for almost 2 months for an answer to my ping.)
This appears to be related to bug 751715. Note the discussion about "mpegaudioversion=1" appearing in one place but not another.
*** Bug 751715 has been marked as a duplicate of this bug. ***
At least the duplicate got an answer from Benjamin Otte: https://bugzilla.redhat.com/show_bug.cgi?id=751715#c3 Benjamin, RPM treats those Provides as exact strings, every character needs to match, even the order of the "(foo)(bar)" pieces. Any smarter logic would have to be implemented at the PackageKit level, but at the cost of more complex / slower RPM database queries, or simply more RPM database queries (which also requires more time, of course). In this case, we'd need PackageKit to query gstreamer0.10(decoder-audio/mpeg)X()(64bit) with X = all the 2³=8 subsets of (mpegaudioversion=1)(mpegversion=1)(layer=3). For each variable you stuff in there, the number of possible Provides to look up will double, i.e. the algorithm is O(2^n). :-(
(FWIW, I suspect that to be robust, you need not only all the subsets, but also all the permutations, which increases the amount of tries for 3 flags to 16.)
Of course, a quick hack to fix this particular issue would just be to blacklist the mpegaudioversion variable, e.g. by replacing "(mpegaudioversion=1)" with "" in PackageKit. But IMHO, GStreamer's upstream semantics need to change to actually match what real-world packaging systems implement, i.e. they need to look up only the flags which are actually defined by the codec, not an arbitrary superset.
I have the same issue with F17-Alpha and gstreamer-0.10.35-2.fc17.
It also affects gstreamer-0.10.36-1.fc17.
mpegaudioversion should be removed in our hacked gst-inspect.
If it builds, there's a test package at: http://koji.fedoraproject.org/koji/taskinfo?taskID=4355300 1) Update this package 2) Remove your mp3 decoder packages 3) Launch Totem with an mp3 4) Success?
works! thanks.
Success here too as far as downloading the decoder properly. Following these instructions, I did encounter an issue where totem doesn't simply continue to play the test file. If I restart totem the file plays as expected. I doubt this is related specifically to this bug, though.
This is working, thank You very much! (Of course, you have to restart totem)
Filed upstream as: https://bugzilla.gnome.org/show_bug.cgi?id=681362
gstreamer-plugins-base-0.10.36-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gstreamer-plugins-base-0.10.36-2.fc17
Steve: you do? You shouldn't have to restart Totem, Totem/GStreamer should pick up the new plugins (via gst_update_registry()) and then try playing the same file/stream again.
(In reply to comment #31) > Steve: you do? You shouldn't have to restart Totem, Totem/GStreamer should > pick up the new plugins (via gst_update_registry()) and then try playing the > same file/stream again. Yes, I have to restart totem.
Mind you f16's plugin search fails similarly, and update to fix this there too would be appreciated.
gstreamer-plugins-base-0.10.36-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Ok, there's a new on with Fedora 18: $ totem Ladykillers.avi (totem:1745): GStreamer-CRITICAL **: gst_mini_object_copy: assertion `mini_object != NULL' failed (totem:1745): GStreamer-CRITICAL **: gst_caps_get_size: assertion `GST_IS_CAPS (caps)' failed (totem:1745): GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object != NULL' failed ** (totem:1745): CRITICAL **: gst_pad_set_caps: assertion `caps != NULL && gst_caps_is_fixed (caps)' failed (totem:1745): Grilo-WARNING **: [registry] grl-registry.c:330: Failed to initialize plugin: '/usr/lib64/grilo-0.2/libgrlflickr.so' (totem:1745): Grilo-WARNING **: [registry] grl-registry.c:330: Failed to initialize plugin: '/usr/lib64/grilo-0.2/libgrltmdb.so' (totem:1745): Grilo-WARNING **: [registry] grl-registry.c:787: Failed to open module: '/usr/lib64/grilo-0.2/libgrlpodcasts.so' ** Message: Missing plugin: gstreamer|1.0|totem|MPEG Video decoder|decoder-video/mpeg, mpegversion=(int)4, parsed=(boolean)true, profile=(string)advanced-simple, level=(string)5 (MPEG Video decoder) ** Message: Missing plugin: gstreamer|1.0|totem|MPEG-1 Layer 3 (MP3) decoder|decoder-audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, parsed=(boolean)true (MPEG-1 Layer 3 (MP3) decoder) ** Message: Missing plugin: gstreamer|1.0|totem|MPEG-1 Layer 3 (MP3) decoder|decoder-audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, parsed=(boolean)true (MPEG-1 Layer 3 (MP3) decoder) ** Message: PackageKit: xid = 37748747 ** Message: PackageKit: Codec nice name: MPEG Video decoder ** Message: PackageKit: ignoring field named parsed ** Message: PackageKit: ignoring field named profile ** Message: PackageKit: ignoring field named level ** Message: PackageKit: field is: mpegversion, type: gint ** Message: PackageKit: structure: gstreamer1.0(decoder-video/mpeg)(mpegversion=4)()(64bit) ** Message: PackageKit: Codec nice name: MPEG-1 Layer 3 (MP3) decoder ** Message: PackageKit: ignoring field named parsed ** Message: PackageKit: field is: mpegaudioversion, type: gint ** Message: PackageKit: field is: mpegversion, type: gint ** Message: PackageKit: field is: layer, type: gint ** Message: PackageKit: structure: gstreamer1.0(decoder-audio/mpeg)(mpegaudioversion=1)(mpegversion=1)(layer=3)()(64bit) ** Message: PackageKit: Did not install codec: GDBus.Error:org.freedesktop.PackageKit.Modify.NoPackagesFound: failed to find codec ** Message: No installation candidate for missing plugins found. $ Any idea?
After installing the plugins manually, rhythmbox is playing the mp3-file. But totem is still missing the plugins. What goes on here, is this because of an F17->F18 upgrade?
Steve: possibly rhythmbox still uses GStreamer 0.10 and you installed the mp3 plugin for GStreamer 0.10, while totem uses GStreamer 1.0, which needs a separate plugin made for 1.0 ?
Yo(In reply to comment #37) > Steve: possibly rhythmbox still uses GStreamer 0.10 and you installed the > mp3 plugin for GStreamer 0.10, while totem uses GStreamer 1.0, which needs a > separate plugin made for 1.0 ? You are right. Totem (or gstreamer) does not find gstreamer1-plungins-bad-freeworld for mp3. After installing it manually it works. Can someone reopen the bug-report?
Please see also here: https://bugzilla.redhat.com/show_bug.cgi?id=895816
Yes, f18 folks with gstreamer apps should follow bug #895816 (to be fixed in PackageKit-0.8.7 update coming soon)
That's a separate issue. But this bug also still exists (see the comments in that bug), and the fix needs to be forward-ported to GStreamer 1.0.
gstreamer1-plugins-bad-free-1.0.5-1.fc18, gstreamer1-plugins-good-1.0.5-1.fc18, gstreamer1-1.0.5-1.fc18, empathy-3.6.3-1.fc18, gstreamer1-plugins-base-1.0.5-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-0543/gstreamer1-plugins-base-1.0.5-2.fc18,empathy-3.6.3-1.fc18,gstreamer1-plugins-bad-free-1.0.5-1.fc18,gstreamer1-plugins-good-1.0.5-1.fc18,gstreamer1-1.0.5-1.fc18
Plugin search works very well with this new packages. Thank you guys!
gstreamer1-plugins-bad-free-1.0.5-1.fc18, gstreamer1-plugins-good-1.0.5-1.fc18, gstreamer1-1.0.5-1.fc18, empathy-3.6.3-1.fc18, gstreamer1-plugins-base-1.0.5-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Hi, the problem seem to be still present: $rpm -q gstreamer1-plugins-bad-free gstreamer1-plugins-good gstreamer1 empathy gstreamer1-plugins-base gstreamer1-plugins-bad-free-1.0.6-1.fc18.x86_64 gstreamer1-plugins-good-1.0.6-1.fc18.x86_64 gstreamer1-1.0.6-1.fc18.x86_64 empathy-3.6.4-2.fc18.x86_64 gstreamer1-plugins-base-1.0.6-1.fc18.x86_64 After searching for a mp3 plugin, Amarok end up with "Couldn't find plugin in any configured software source"
Do you have rpmfusion-free-release installed? There's no MP3 plugin in the default Fedora repositories.
Re: comment #45 Separate issue, see comment #40 and comment #41
comment #46: yes, I have rpmfusion-* repos enabled. comment #47: bug #895816 is closed and should be fixed in gstreamer1-*-1.0.5, you stated it should be fixed in PackageKit-0.8.7. I have gstreamer1-*-1.0.6 and PackageKit-0.8.7-1, so it doesn't seem to me as a #895816
My primary test-case for GStreamer codec installation has been "soundconverter -d" after removing packages like gstreamer-plugins-ugly. Adding an MP3 file and starting conversion triggers missing codec installation, which previously has crashed gnome-packagekit: https://admin.fedoraproject.org/updates/FEDORA-2013-3228 With the fixed gnome-packagekit, this is what is searched for: ** Message: PackageKit: xid = 0 ** Message: PackageKit: Codec nice name: MPEG-1 Layer 3 (MP3) decoder ** Message: PackageKit: ignoring field named parsed ** Message: PackageKit: field is: mpegversion, type: gint ** Message: PackageKit: field is: layer, type: gint ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) And "gstreamer-plugins-ugly-0.10.19-5.fc18 (64-bit)" is found correctly.
comment 49: not sure what you meant, but this is what I'm getting: ** Message: PackageKit: Codec nice name: MPEG-1 Layer 3 (MP3) decoder ** Message: PackageKit: ignoring field named parsed ** Message: PackageKit: field is: mpegversion, type: gint ** Message: PackageKit: field is: layer, type: gint ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit) ** Message: PackageKit: Did not install codec: GDBus.Error:org.freedesktop.PackageKit.Failed: Could not find plugin in any configured software source
> not sure what you meant Well, if you return to the reason this ticket has been opened, what you report is not the original problem. The original problem was a mismatch between what was searched for and what was provided by packages. And even with the original problem fixed, F18 and older would cause gnome-packagekit to crash rather than work properly. > ** Message: PackageKit: structure: gstreamer0.10(decoder-audio/mpeg) > (mpegversion=1)(layer=3)()(64bit) $ repoquery --whatprovides 'gstreamer0.10(decoder-audio/mpeg)(mpegversion=1)(layer=3)()(64bit)' gstreamer-plugins-ugly-0:0.10.19-10.fc19.x86_64 Similarly for F18. If PackageKit doesn't find it, perhaps you're facing a different problem.
Examples of problems you could be facing: * rpmfusion-free-release not set up properly, e.g. the .repo files disabled somehow. * A bad RPM Fusion mirror with faulty metadata. * No access to any of the RPM Fusion mirrors, causing yum to run out of mirrors to try. etc.