i'm not quite sure whether or not this issue might be for upstream. but according to the forums this might be distribution specific. i found a similar to same issue on the arch linux tracker. certain media (e.g. h264, m4a, etc.) fails to play on latest revisions (e.g. r32308 and earlier). xbmc.log shows the following: 11:26:01 T:3034703728 M:2810228736 ERROR: Unable to load /usr/lib/xbmc/system/players/dvdplayer/avcodec-52-i486-linux.so, reason: /usr/lib/xbmc/system/players/dvdplayer/avcodec-52-i486-linux.so: undefined symbol: NeAACDecSetConfiguration 11:26:01 T:3034703728 M:2810228736 ERROR: CDVDDemuxFFmpeg::Open - failed to load ffmpeg libraries 11:26:01 T:3034703728 M:2810228736 ERROR: Init: Error creating demuxer 11:26:01 T:3034703728 M:2810228736 ERROR: CAudioDecoder: Unable to Init Codec while loading file /mnt/data/xxx.m4a 11:26:01 T:3034703728 M:2810228736 ERROR: Playlist Player: skipping unplayable item: 0, path [/mnt/data/xxx.m4a] ldd xbmc.bin: ldd /usr/lib/xbmc/xbmc.bin linux-gate.so.1 => (0xb786b000) libva-0.31.1.1.so.1 => /usr/lib/libva-0.31.1.1.so.1 (0xb784c000) libva-glx-0.31.1.1.so.1 => /usr/lib/libva-glx-0.31.1.1.so.1 (0xb7846000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb783e000) libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb782d000) libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb7820000) libmicrohttpd.so.5 => /usr/lib/libmicrohttpd.so.5 (0xb77e9000) librt.so.1 => /lib/librt.so.1 (0xb77e0000) libdl.so.2 => /lib/libdl.so.2 (0xb77dc000) libSDL_mixer-1.2.so.0 => /usr/lib/libSDL_mixer-1.2.so.0 (0xb77c8000) libsmbclient.so.0 => /usr/lib/libsmbclient.so.0 (0xb738f000) libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0xb732e000) libmpeg2.so.0 => /usr/lib/libmpeg2.so.0 (0xb730f000) libwavpack.so.1 => /usr/lib/libwavpack.so.1 (0xb72e9000) libz.so.1 => /lib/libz.so.1 (0xb72d6000) liblzo2.so.2 => /usr/lib/liblzo2.so.2 (0xb72b4000) libpthread.so.0 => /lib/libpthread.so.0 (0xb729a000) libass.so.4 => /usr/lib/libass.so.4 (0xb7281000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7215000) libGLEW.so.1.5 => /usr/lib/libGLEW.so.1.5 (0xb71d2000) libGL.so.1 => /usr/lib/opengl/nvidia/lib/libGL.so.1 (0xb7107000) libmad.so.0 => /usr/lib/libmad.so.0 (0xb70f0000) libfribidi.so.0 => /usr/lib/libfribidi.so.0 (0xb70df000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb705f000) libpcre.so.0 => /lib/libpcre.so.0 (0xb7031000) libpcrecpp.so.0 => /usr/lib/libpcrecpp.so.0 (0xb7027000) libcdio.so.7 => /usr/lib/libcdio.so.7 (0xb7008000) libm.so.6 => /lib/libm.so.6 (0xb6fe2000) libsamplerate.so.0 => /usr/lib/libsamplerate.so.0 (0xb6e76000) libmms.so.0 => /usr/lib/libmms.so.0 (0xb6e6b000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6de8000) libogg.so.0 => /usr/lib/libogg.so.0 (0xb6de2000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6dba000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6c41000) libasound.so.2 => /usr/lib/libasound.so.2 (0xb6b90000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6a78000) libXtst.so.6 => /usr/lib/libXtst.so.6 (0xb6a72000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6a63000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb6a2b000) libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb69d0000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libstdc++.so.6 (0xb68e7000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1 (0xb68cb000) libc.so.6 => /lib/libc.so.6 (0xb6785000) /lib/ld-linux.so.2 (0xb786c000) libva-x11-0.31.1.1.so.1 => /usr/lib/libva-x11-0.31.1.1.so.1 (0xb677d000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6771000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb676b000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb6750000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb674c000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6746000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb673b000) libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb66cb000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb66c6000) libmikmod.so.3 => /usr/lib/libmikmod.so.3 (0xb668c000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0xb6683000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0xb664d000) libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6643000) libtdb.so.1 => /usr/lib/libtdb.so.1 (0xb6635000) libresolv.so.2 => /lib/libresolv.so.2 (0xb6620000) libnsl.so.1 => /lib/libnsl.so.1 (0xb6609000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb65d6000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb65a8000) libenca.so.0 => /usr/lib/libenca.so.0 (0xb6582000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb655e000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb6547000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb6538000) libnvidia-tls.so.256.35 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.256.35 (0xb6536000) libnvidia-glcore.so.256.35 => /usr/lib/libnvidia-glcore.so.256.35 (0xb5006000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb4f3a000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb4f13000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb4ec2000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb4eb9000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb4ea1000) libuuid.so.1 => /lib/libuuid.so.1 (0xb4e9b000) this happens in each situation, ffmpeg used as an internal and external library. above ldd output refers to a build with internal ffmpeg. Reproducible: Always Steps to Reproduce: 1. playback media from description Actual Results: playback fails Expected Results: playback should start
Seems an upstream issue indeed. I asked about this problem on the XBMC forums: http://forum.xbmc.org/showthread.php?p=587677 A quick fix is to add the following to the XBMC startup script: export LD_PRELOAD="/usr/lib/libfaad.so"
Please reopen this bug, as the problem seems not upstream after all. The problem (for me at least) is solved if XBMC is built/linked without --as-needed flag, by adding the usual snippet to the ebuild: pkg_setup() { append-ldflags $(no-as-needed) }
... which usually means the package in question is linking things in the wrong order, or it's relying on implicit symbol loading. so it's still a bug upstream.
I think it's better to add a workaround and make things working while upstream fixes it. Making users happy and get something that actually works. If the XBMC maintainer here would actually use xbmc, it would have been fixed in one hour.
once again you've shown you like to make statements you havent a clue about. xbmc works fine for me. perhaps if you actually cared you'd locate the root cause and report back. but we all know you probably won't do any such thing and instead just whine.
(In reply to comment #5) > once again you've shown you like to make statements you havent a clue about. > xbmc works fine for me. > > perhaps if you actually cared you'd locate the root cause and report back. but > we all know you probably won't do any such thing and instead just whine. > Sorry SpanKY, but the 9999 xbmc ebuild that is now in portage does not "work fine". Even if it happens to build and link properly, it has all sorts of bugs introduced by the refusal to use --disable-external-python and --disable-external-ffmpeg. This DOES break addons and playback of some formats. But this is the "Gentoo Way™". It has been this way for more than a year now. Everyone who needs XBMC on Gentoo has a fixed ebuild of their own, which "works for them" just like the ebuild in portage works for you. The problem is, it is ONLY you that it does work fine for.
this bug has nothing to do with python. you might also want to try doing real research on that issue before spouting bogus claims. as for ffmpeg, vague claims of "it doesnt work" gets you nowhere -- post real details and assist in root causing real problems. otherwise, i'm not interested in such things, nor am i interested in populating ebuilds with unmaintainable hacks. if you cant handle that, then stick with your own custom ebuilds. no sweat off my back.
Sorry for the "vague claims" :) You're right, of course, this has nothing to do with this particular bug. I will hopefully post some more useful reports once I give the official ebuild another try. Anyway, your work on these ebuilds is highly appreciated :)
thanks, that was a surprisingly useful response. in general, the live scm ebuilds are provided for developers to experiment and validate upstream code. they are certainly not intended as an every day replacement of release ebuilds. so while releases might see workarounds (such as the python issue in xbmc-9.11-r5), i have no interest in adding these things to the live scm ebuilds. users who hit such issues (non-packaging related) shouldnt be reporting these to distros and expecting them to fix. they should either be assisting in the fix upstream or sticking to the releases.
(In reply to comment #5) > xbmc works fine for me. The "most famous words" in software engineering. "Works for me" doesn't mean anything. Once again you've shown how you deal with bugs and in particular with users just asking for fixes.
since you clearly dont get it, go away now