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 required Reproducible: Always 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) Actual Results: Crash Expected Results: mp3 played
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 vulnerable ebuilds. 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 libraries.
> 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.
