Please create ebuild. Reproducible: Always Steps to Reproduce: 1. 2. 3.
I think it could be good if amarok depended on gst-plugins-mad when gstreamer is USEd, if it doesn't then we wouldn't be able to play mp3-files. (at least not without installing it manually).
A forgot, at least when cjk is not used you may copy amarok-1.1.ebuild to amarok-1.1.1.ebuild, and regenerate the digest.
in portage.
hi, amarok-1.1_beta2 and higher is in package.mask, because there is/was 100% CPU usage with gstreamer. Is this still the case with Amarok 1.1.1? If it's not the case I suggest removing incorrect versions from the tree and remove it from package.mask.
it is in package.mask because I am not yet certain that it is stable yet. I will remove it from package.mask when it is ready.
What is the status of amarok 1.1.1 ebuild? I have heard of gentoo gst package problems, but they should not prevent amarok 1.1.1 from being unmasked. If gentoo gst packages can't be fixed, the ebuild could mention something about the problem and inform the user to use arts or xine engine instead in case of this 100% cpu problem. Personally I have been using amarok with gst engine for a long time without any problems. I know that gst engine had problems in the past, but not anymore. And why is this report in resolved & fixed state when the ebuild is masked?
it is in resolved/fixed because it is fixed in portage by placing it in package.mask and not letting you emerge a broken package. The problem is upstream, and I will unmask it once it is fixed upstream.
The amaroK team would like to see the gentoo amaroK packager replaced. We feel that this packager is lacking the required competence for this job. There have been numerous problems with his packages in the past, which could have been solved quickly if the packager would have checked back with us. Also, it is not acceptable for us that amaroK 1.1.1 is still "masked", while other distributions were able to provide working packages two days after our release. --Mark (amaroK maintainer)
Mark: 1) I contacted Stefan Bogner about one month ago regarding the problem that is preventing amarok from leaving package.mask. He never responded (see below) 2) The stability of a package is decided by Gentoo, not upstream developers. package.mask is used for packages that Gentoo developers feel are not stable. 3) There is no amarok packager. If you would like to volunteer, then be my guest to submit patches for the amarok ebuild which I will gladly add with the utmost speed and "competence" 4) I put stability ahead of burning edge software. The amarok ebuild itself has no known problems. It is the package provided upstream that has a regression against the 1.0 release which is preventing me from unmasking the ebuild as I discussed with Stefan last month. 5) The Gentoo amarok-1.1.1 package was availible on Oct 9 (the same day as the release), but it was left in package.mask because it was not deemed stable due to the mentioned bug. 6) I would love to see the "numerous problems" with the ebuild you mention as no such bugs have been submitted to bugzilla that were not squashed in a competent and timely manner. If you see such problems, kindly use bugzilla as that is the best way to get them fixed. Subject: Re: amaroK ebuild From: Jeremy Huddleston <eradicator@gentoo.org> To: Stefan Bogner <sbogner@suse.de> In-Reply-To: <200409291601.55718.sbogner@suse.de> References: <200409281449.02112.sbogner@suse.de> <200409282120.51558.sbogner@suse.de> <1096407802.10838.54.camel@cid.outersquare.org> <200409291601.55718.sbogner@suse.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V16/e3g/F6yaxBeMpX8p" Date: Sun, 10 Oct 2004 10:57:29 -0700 Message-Id: <1097431050.13564.38.camel@cid.outersquare.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 X-Evolution-Transport: smtp://eradicator;auth=CRAM-MD5@dev.gentoo.org/;use_ssl=when-possible X-Evolution-Account: eradicator@gentoo.org X-Evolution-Fcc: email://1066994301.24519.0@eradicator/INBOX/Sent X-Evolution-Format: text/plain X-Evolution-Source: imap://jeremy@cid.outersquare.org/ --=-V16/e3g/F6yaxBeMpX8p Content-Type: text/plain? Content-Transfer-Encoding: quoted-printable? ? > Hmm, there are other people that reported the gstreamer-plugin thing in o=? ur=20? > irc channel as well. I wasn't able to reproduce it, though, same for the=20? > other devs.=20? >=20? > We'll see if we can find a solution for that, though, at least we have so=? meone=20? > with those problems in our irc channel :)? ? I noticed some gstreamer fixes in the ChangeLog, but I didn't see any? reference to 100% CPU usage. Were you guys able to get this problem? solved in 1.1.1?? ? --Jeremy? ? --=-V16/e3g/F6yaxBeMpX8p Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBaXgJOpjtAl+gMRURAkhKAKCC7IZeSNvHLh4gDm6zR57TwvN3IgCglMqT pWs2iVqanIW2nNahtQAz06E= =8HNN -----END PGP SIGNATURE----- --=-V16/e3g/F6yaxBeMpX8p--
Jeremy, is this 100% CPU usage problem possibly due to use of gst-plugins-ffmpeg for decoding mp3, while the recommended is to use gst-plugins-mad? If yes, amarok ebuild should depend on gst-plugins-mad if gstreamer USE flag is set. ffmpeg plugin seems to be known to be broken for mp3. I went on and uninstalled my mad plugin, and installed ffmpeg plugin instead. After this, I can confirm the 100% CPU usage, but only with gst-plugins-ffmpeg. However, this works properly: gst-launch-0.8 filesrc location=some.mp3 ! ffdec_mp3 ! alsasink So the problem seems to be with gst-plugins-ffmpeg and the way how the more feature rich gst-engine of >=amarok-1.1 uses gstreamer, exposes this problem. I spoke to one gentoo user yesterday, and he had no mad plugin installed, and said amarok is using 100% CPU. I instructed him on how to install mad plugin, but he did not get it working. Here are the errors he was getting: $ gst-launch-0.8 filesrc location=/path/to/some.mp3 ! mad ! alsasink GStreamer-CRITICAL **: Factory for `mad' has no type. This probably means the plugin wasn't found because the registry is broken. The plugin GStreamer was looking for is named 'mad' and is expected in file '/usr/lib/gstreamer-0.8/libgstmad.so'. The registry for this plugin is located at '/var/lib/cache/gstreamer-0.8/registry.xml' WARNING: erroneous pipeline: no element "mad" He had run gst-register-0.8 and gst-inspect-0.8 reported mad plugin properly. I told him to report this as a gstreamer bug here in gentoo bugzilla. See also the following: http://bugs.kde.org/show_bug.cgi?id=91063 http://bugzilla.gnome.org/show_bug.cgi?id=156721 Finally, it's a shame if amarok does not have a gentoo packager. I am sure these things would have been tackled long ago if there was one.
We debugged the ffmpeg problem with Mark, and found out that ffmpeg plugin needs a separate demuxer element to work with mp3. Gst people are aware of this problem, and this is a quote from gst ffmpeg maintainer: "for now, we just tell them to install mad because that's faster than fixing our autopluggers" So the amarok ebuild needs to require gst-plugins-mad if gstreamer USE flag is used.
Sami: I don't use gstreamer as my experience with it has been nothing but a derailed rollercoaster train wreck. As such, I decided to disable the gstreamer support from building in amarok and unmasked it yesterday. I would like to give people the option to use gstreamer, but this is the first response I've gotten regarding a possible cause to the problem, so thank you for letting me know. If the user has both the mad and ffmpeg plugin installed, does amarok/gstreamer prefer the mad plugin?
Yes, mad plugin has higher priority for mp3, so it will be used if both are installed.
Alright Sami, thanks for your help.
the bug is still present even with xmms-mad enabled (see dup bug) markey: THIS is why it was in package.mask.
*** Bug 70533 has been marked as a duplicate of this bug. ***
Well, it is a gstreamer bug in case of no hardware mixing and no dmix. See also my second URL on comment #10. http://bugzilla.gnome.org/show_bug.cgi?id=156721
our gst-plugins-alsa ebuild states it has known problems on some hardware, people using it should've been aware of this!
err... I meant gst-mad in my above comment... obviously xmms-mad has nothing to do with it... ;p I'm marking this UPSTREAM as I have no desire to fix gstreamer
