./configure --enable-external-libraries forces XBMC to use external Python interpreter (which is default 2.6 for Gentoo). Most of plugins for XBMC crash in such way. There is experimental branch for porting XBMC to py2.6, but currently the best way is to use internal python 2.4
same problem here I've made a local portage tree and tried --enable-external-ffmpeg \ --enable-external-liba52 \ --enable-external-libmpeg2 \ --enable-external-libass \ --enable-external-libogg \ --enable-external-libwavpack \ --disable-external-python instead of external libraries and all non-working plugins like Youtube, VideoMonkey, ... work perhaps it's better to use not all external libraries as default?
(In reply to comment #1) > perhaps it's better to use not all external libraries as default? I've done the same and agree with you.
I need to +1 or "me too" this. After a few months of frustration wondering why various plugins refused to work, I edited my own ebuild in an overlay with the options in econf that zehner specified. Now the plugins I like to use (such as TED Talks and YouTube) work great. Thanks zehner.
Any feedback on this change? Would really love for this one to go upstream (sabayon)!
i dont use scripts in xbmc, so i dont really know what you're testing. ive had xbmc-9.11-r4 force python-2.4 usage though, so see if that works any better for you.
I've tried xbmc with python-2.4, 2.5 and 2.6 a few months ago, but none of them resolves the problem. If I understand the problem correctly, than its not a matter of the python-version. Xbmc has made a few patches/additions to python, which aren't upstream. The included python has this patches, python as an external library misses this features. I'm not a python developer, so I can't say, what kind of changes are made, but many plugins (i.e. VideoMonkey, Youtube, ...) only work with internal python. I hope this gets better with the new AddOn-Manager in the next release
(In reply to comment #6) > If I understand the problem correctly, than its not a matter of the > python-version. Xbmc has made a few patches/additions to python, which aren't > upstream. The included python has this patches, python as an external library > misses this features. You're spot on. I guess the only option is to keep hacking your own ebuilds so that XBMC uses the internal Python 2.4 that it bases its plugin API on -- seeing as this is "resolved fixed", and SpanKY doesn't use plugins at all, it's clear we'll get no love here. Perhaps you can use the ridiculously obscure portage syntax in order to enable an svn verion without hacking ebuilds (see bug 282765 where I was told off for using a bug report as a support forum because I didn't know of the ** notation to enable un-hand-hacked svn builds of pre-9.11 XBMC, and 9.04 was stuffed). Anyway, an svn version doesn't seem wise to use at this time given the transitional state of XBMC and its plugin API -- you'll probably just cause yourself more grief.
why dont you chill out and actually read what i said instead of putting words in my mouth you guys still havent posted info for me to reproduce with
reopen ...
(In reply to comment #5) > i dont use scripts in xbmc, so i dont really know what you're testing. ive had > xbmc-9.11-r4 force python-2.4 usage though, so see if that works any better for > you. > xbmc has the ability to use extensions (plugins and scripts). the "extension engine" is based on python. atm the "extension engine" of xbmc uses python24. thus all of available plugins/scripts are based on python24. using python26 renders all plugins/scrips incompatible. since xbmc bundles python24 there's no problem using plugins/scripts with --disable-external-python. gentoo uses python26 as default. so using --enable-external-python leads to the mentioned incompatibility between plugins/scripts and the engine of xbmc. last week there was still a note on the roadmap of xbmc to migrate to python26 for the 10.05 release. but it's not there anymore: http://trac.xbmc.org/roadmap
(In reply to comment #1) > same problem here > > I've made a local portage tree and tried > > --enable-external-ffmpeg \ > --enable-external-liba52 \ > --enable-external-libmpeg2 \ > --enable-external-libass \ > --enable-external-libogg \ > --enable-external-libwavpack \ > --disable-external-python > > instead of external libraries and all non-working plugins like Youtube, > VideoMonkey, ... work > > perhaps it's better to use not all external libraries as default? > seems to be a bit "overkill". please check ./configure --help: --enable-external-libraries enable use of all supported external libraries (default is no) 'Linux only' --enable-external-ffmpeg enable use of external ffmpeg libraries (default is no) 'Linux only' --enable-external-liba52 enable use of external liba52 library (default is no) 'Linux only' --enable-external-libdts enable use of external libdts library (default is no) 'Linux only' --enable-external-python enable use of external python library (default is no) 'Linux only'
(In reply to comment #11) > seems to be a bit "overkill". please check ./configure --help: No, it's not overkill, let me show you the difference: econf \ --disable-ccache \ --disable-optimizations \ --enable-external-libraries \ --disable-external-python \ --enable-goom \ --enable-gl \ $(use_enable avahi) \ $(use_enable css dvdcss) \ $(use_enable debug) \ $(use_enable aac faac) \ $(use_enable joystick) \ $(use_enable midi mid) \ $(use_enable profile profiling) \ $(use_enable pulseaudio pulse) \ $(use_enable vdpau) \ $(use_enable xrandr) $ ldd /usr/share/xbmc/xbmc.bin | grep python libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xaafc1000) econf \ --disable-ccache \ --disable-optimizations \ --enable-external-ffmpeg \ --enable-external-liba52 \ --enable-external-libmpeg2 \ --enable-external-libass \ --enable-external-libogg \ --enable-external-libwavpack \ --disable-external-python \ --enable-goom \ --enable-gl \ $(use_enable avahi) \ $(use_enable css dvdcss) \ $(use_enable debug) \ $(use_enable aac faac) \ $(use_enable joystick) \ $(use_enable midi mid) \ $(use_enable profile profiling) \ $(use_enable pulseaudio pulse) \ $(use_enable vdpau) \ $(use_enable xrandr) $ ldd /usr/share/xbmc/xbmc.bin | grep -i python (nothing) Using --enable-external-libraries and --disable-external-python means that external python is still used.
(In reply to comment #12) > (In reply to comment #11) > > > seems to be a bit "overkill". please check ./configure --help: > > No, it's not overkill, let me show you the difference: sorry, i guess i was not clear enough. i wasn't referring to the python libs. i was referring to: > --enable-external-libmpeg2 \ > --enable-external-libass \ > --enable-external-libogg \ > --enable-external-libwavpack \ these don't show up while executing ./configure --help.
ah sorry for the noise. maybe they do appear. i checked this while using the svn source... Oo (slap me...)
(In reply to comment #10) > renders all plugins/scrips incompatible. since xbmc bundles python24 there's > no problem using plugins/scripts with --disable-external-python. gentoo uses > python26 as default. so using --enable-external-python leads to the mentioned > incompatibility between plugins/scripts and the engine of xbmc. Just to clarify hal's point -- yes, linking against python-2.6 is bad, but even linking against a Gentoo python-2.4 is bad. In SpanKY's latest build he has included a dependency on python 2.4, which was a good move, and actually does help some plugins work better (even though it's an "external" python 2.4), but there are some plugins that simply rely on whatever features that are included in the bundled 2.4 that XBMC provides in its own source.
sidenote: there's an ongoing discussion on the xbmc forums related to python26 migration: http://forum.xbmc.org/showthread.php?t=70349
i'm not going to merge an extended list of configure flags to the ebuild, so dont bother discussing that route
(In reply to comment #17) > i'm not going to merge an extended list of configure flags to the ebuild, so > dont bother discussing that route > Could you please elaborate on this? I implemented the changes suggested in comment #12 in five minutes, and it fixed all the problems. Building against the internal interpreter is the correct solution because of the changes XBMC have made upstream.
For the record, following addition fixed all my issues: --enable-external-libraries \ --disable-external-python \ Python 2.6 branch is idling currently, developers are focusing on XBMC Dharma.
(In reply to comment #19) > For the record, following addition fixed all my issues: > > --enable-external-libraries \ > --disable-external-python \ > > Python 2.6 branch is idling currently, developers are focusing on XBMC Dharma. > same here. It would be nice, if the ebuild was changed this way or these was exposed as use.
(In reply to comment #19) > For the record, following addition fixed all my issues: > > --enable-external-libraries \ > --disable-external-python \ > > Python 2.6 branch is idling currently, developers are focusing on XBMC Dharma. > This works for me as well, using an edited -9999 ebuild. I think the svn build more or less represents the to-be-released Dharma, so this change would be sufficient. As the add-on system will be a much more integrative part of xbmc now (instead of being more or less bolted on, as before) I think having a working python is essential now.
I've tried Beta1 and Beta2 of xbmc 10.0 and even the new Youtube AddOn has problems with external python. But --enable-external-libraries \ --disable-external-python \ works in contrast to 9.11, so I think it's the best way for a fully working xbmc.
xbmc-9.11-r5 builds against internal python
(In reply to comment #23) > xbmc-9.11-r5 builds against internal python > that could be a problem. The last time I tried xbmc-9.11, --enable-external-libraries \ --disable-external-python \ doesn't work as expected (see also comment #12). This only works on svn and 10.0!!! I have not tested it, because I use xbmc-10.0 these days, but a few month ago, it doesn't help to use these two lines. In a few weeks this problem should disappear, because 10.0 final is on its way and there the config works as expected
