Package Details: kodi-git r67077.44376d5e9c74-1

Git Clone URL: https://aur.archlinux.org/kodi-git.git (read-only, click to copy)
Package Base: kodi-git
Description: A software media player and entertainment hub for digital media (master branch, gles renderer)
Upstream URL: https://kodi.tv
Licenses: GPL2
Conflicts: kodi, kodi-gbm, kodi-gles, kodi-wayland, kodi-x11
Provides: kodi-common, kodi-gbm, kodi-wayland, kodi-x11
Submitter: BlackIkeEagle
Maintainer: graysky
Last Packager: graysky
Votes: 85
Popularity: 0.001119
First Submitted: 2014-10-23 06:38 (UTC)
Last Updated: 2024-11-23 20:01 (UTC)

Pinned Comments

graysky commented on 2022-06-11 11:49 (UTC)

@laichiaheng - kodi is bound to a specific version of ffmpeg which is generally older than Arch's package. We avoid incompatibilities by using that specific version (ie internal ffmpeg). Recommend that you build kodi in clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.

Latest Comments

« First ‹ Previous 1 .. 42 43 44 45 46 47 48 49 50 51 52 .. 54 Next › Last »

Beretta92 commented on 2011-07-22 12:32 (UTC)

looks like building with gcc45 from AUR fixes the plugins bug, would it be possible to add this to PKGBUILD at least only for 64bits builds thanks

Beretta92 commented on 2011-07-08 10:19 (UTC)

why do you build with multilib?

<deleted-account> commented on 2011-07-08 05:21 (UTC)

I haven't been able to play MP3 audio with this package for the last several builds ... I get the following in xbmc crashlog: ERROR: Unable to load /usr/lib/xbmc/system/libid3tag-x86_64-linux.so, reason: /usr/lib/xbmc/system/libid3tag-x86_64-linux.so: undefined symbol: id3_frametype_obsolete This is running archlinux x86_64 with all of the lastest updates as of this post and compiled with multilib/gcc-multilib 4.6.1-1 ... I have all of multilib-devel group installed

Beretta92 commented on 2011-07-03 19:52 (UTC)

lartza: could you open a bug upstream for this? or add to mine: http://trac.xbmc.org/ticket/11584

lartza commented on 2011-07-03 19:22 (UTC)

Without using totalItems parameter in the xbmcplugin.addDirectoryItem call the items added invoke StartScript instead of RunScriptWithParams.

lartza commented on 2011-07-03 19:07 (UTC)

Well, if you take a look at https://github.com/xbmc/xbmc/blob/master/xbmc/filesystem/PluginDirectory.cpp#L402 it seems that handle is set to -1 on purpose in the RunScriptWithParams method, right? so it should be -1. I noticed that the Chaos Computer Club CCCTV addon works like a charm in archlinux, so after comparing .xbmc/addons/plugin.video.ccctv/default.py and .xbmc/addons/plugin.video.youtube/YouTubeNavigation.py I noticed that ccctv doesn't set the totalItems optional param at all. Youtube addon uses xbmcplugin like this: xbmcplugin.addDirectoryItem(handle=int(sys.argv[1]), url=url, listitem=listitem, isFolder=True, totalItems=size) as you can see from http://code.google.com/p/youtubexbmc/source/browse/trunk/YouTubeNavigation.py#320 Now the size is set to 0 with search and explore. Changing the default to 1 didn't help, so I removed totalItems=size from xbmcplugin.addDirectoryItem call completely. Now I can search and explore youtube, hooray! '%s/, totalItems=size//g' is the quick and dirty fix for this. The real bug may be somewhere in the https://github.com/xbmc/xbmc/blob/master/xbmc/interfaces/python/xbmcmodule/xbmcplugin.cpp#L59 maybe the new gcc brings it up, I'm not really a c++ wizard so...

lartza commented on 2011-07-03 14:58 (UTC)

The bug must be in the xbmc code since creating new handle returns -1. so xbmc fails to create the handle for python (for some unknown reason). adding sys.argv[1] = 0 to .xbmc/addons/plugin.video.youtube/default.py doesn't help, since the handle failed in the first place. The handle seems to come from https://github.com/xbmc/xbmc/blob/master/xbmc/filesystem/PluginDirectory.cpp getNewHandle on line 60. Why int handle = (int)globalHandles.size() returns -1 is beyond me. CSingleLock lock(m_handleLock) rely on boost's unique_lock so maybe there's something. However downgrading boost to 1.42 doesn't seem to fix this.

lartza commented on 2011-07-01 14:42 (UTC)

rolling back to glew 1.5.8-1 doesn't fix youtube with xbmc-10.1 or xbmc-git. same invalid handle error in the debug.

<deleted-account> commented on 2011-06-30 19:52 (UTC)

Any progress in finding the bug?

<deleted-account> commented on 2011-06-19 16:48 (UTC)

If it is really a dependency bug, it could be related to the last version of glew. Rolling it back to version 1.5.8-1 may fix the bug.

« First ‹ Previous 1 .. 42 43 44 45 46 47 48 49 50 51 52 .. 54 Next › Last »