After switching on debugging on amarok to find the cause of continuous crashes I found the problem
stemmed from the mad decode code in xine-lib (which had not been built with USE=mad).
After recompiling xine-lib with USE=mad and recompiling amarok, the crashes went away
A line should be added to tha amarok ebuild requiring xine-lib be built with USE=mad if mp3 support is
Steps to Reproduce:
1. emerge xine-lib without the mad useflag set
2. emerge amarok with xine useflag set
3. attempt to play an mp3 file using amarok (through the xine engine)
Hmm I'll try to find a better solution, seems like internal mad still has
problem, but it should be related to broken mp3s...
(In reply to comment #1)
> Hmm I'll try to find a better solution, seems like internal mad still has
> problem, but it should be related to broken mp3s...
Diego, please don't use internal libs. Rather hard disable them if possible.
Apart from the additional used memory having two versions of the same library in
the system, in case of vulnerabilites in those included libs the whole process
to from fixing, to arch testing, to GLSA release gets more complicated and takes
more time and work for the security team, arch testers an package maintainers.
Also there's always the chance to miss one of these "hidden" libraries and ship
For now we have to live with the inability of portage to deal with second level
dependencies, but using internal libs is fugly and not a solution.
mad useflag enables the use of EXTERNAL mad that is supposed NOT to be the
right way to do.
For 1.0 series this is a patch, for 1.1 the patch is on upstream but the
default is still to use the internal libraries.
I was already thinking of removing the mad useflag and default to the external
library, but this is not easily feasible as you can't disable it at all.
So, also if I know how to deal with them, for now the default will be this.
BTW, xine-lib (with vlc) is the one that uses the more external libraries
possible. It also had external ffmpeg support before 1.1 that changes the
required version that we don't have on portage. So no need to state that as
xine-lib is non-optimal, as mplayer and gstreamer uses internal copies of many
> mad useflag enables the use of EXTERNAL mad that is supposed NOT to be the
right way to do.
Just because upstream ships so? External/shared libs should _always_ be used,
unless it's not possible for a reason. Flagging the usage of internal vs
external libs is inappropriate imho, and a hard dependency on the external lib
the way to go.
Now mad useflag enable the use of mad decoder AND defaults to use the external
library. (Internal) FFMPEG is used for decoding mp3 audio track from videos,
so it doesn't lose too much functionality without mad useflag.
The same goes for a52 and dts flags (enable/disable, with external libraries).
I was *already* planning to do this before, but as upstream wasn't so sure
about this, I preferred wait a bit.
Consider that our xine-lib is heavily patched to enable/disable optional
dependencies and modules, and this makes me the only responsible in case of
bugs. So please don't bitch about internal libraries *to me*, as I'm already
doing this since I come here!
By the way, xine-lib still uses internal libdvdnav... while I was the one
pushing to use the external one, the internal is/was *way more* reliable, and
I'm *NOT* going to change this.