Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and powerful skinning engine, it's available for Android, BSD, Linux, macOS, iOS and Windows.

Overview

Kodi Logo

websitedocscommunityadd-ons

License HitCount Documentation PRs Welcome Contributions Welcome Build Commits

Welcome to Kodi Home Theater Software!

Kodi is an award-winning free and open source software media player and entertainment hub for digital media. Available as a native application for Android, Linux, BSD, macOS, iOS, tvOS and Windows operating systems, Kodi runs on most common processor architectures.

Created in 2003 by a group of like minded programmers, Kodi is a non-profit project run by the XBMC Foundation and developed by volunteers located around the world. More than 500 software developers have contributed to Kodi to date, and 100-plus translators have worked to expand its reach, making it available in more than 70 languages.

While Kodi functions very well as a standard media player application for your computer, it has been designed to be the perfect companion for your HTPC. With its beautiful interface and powerful skinning engine, Kodi feels very natural to use from the couch with a remote control and is the ideal solution for your home theater.

Give your media the love it deserves

Kodi can be used to play almost all popular audio and video formats around. It was designed for network playback, so you can stream your multimedia from anywhere in the house or directly from the internet using practically any protocol available.

Point Kodi to your media and watch it scan and automagically create a personalized library complete with box covers, descriptions, and fanart. There are playlist and slideshow functions, a weather forecast feature and many audio visualizations. Once installed, your computer or HTPC will become a fully functional multimedia jukebox.

Kodi

Getting Started

Kodi's developers work hard to make it support a large range of devices and operating systems. We provide final as well as development builds. To get started, head over to the downloads section and simply select the platform that you want to install it on. A quick start guide to help you get acquainted with Kodi is available in our wiki.

How to Contribute

Kodi is created by users for users and we welcome every contribution. There are no highly paid developers or poorly paid support personnel on the phones ready to take your call. There are only users who have seen a problem and done their best to fix it. This means Kodi will always need the contributions of users like you. How can you get involved?

  • Coding: Developers can help Kodi by fixing a bug, adding new features, making our technology smaller and faster and making development easier for others. Kodi's codebase consists mainly of C++ with small parts written in a variety of coding languages. Our add-ons mainly consist of python and XML. For more information, please have a look at our contributing guide.
  • Helping users: Our support process relies on enthusiastic contributors like you to help others get the most out of Kodi. The #1 priority is always answering questions in our support forums. Everyday new people discover Kodi, and everyday they are virtually guaranteed to have questions.
  • Localization: Translate Kodi, add-ons and skins into your native language.
  • Add-ons: Add-ons are what make Kodi the most extensible and customizable entertainment hub available. Get started building an add-on.
  • Documentation: Kodi's wiki pages are the hub for information about Kodi and surrounding ecosystem. Help make our documentation better by writing new content or correcting existing material.

Not enough free time? No problem! There are other ways to help Kodi.

  • Spread the word: Share Kodi with the world! Tell your friends and family about how Kodi creates an amazing entertainment experience. Stay up to date on the latest stories about Kodi reading our news section, follow us on Twitter and Facebook, or star Kodi's repo if you want to follow development.
  • Donate: We are always happy to receive a donation. Donations are typically used for travel to attend conferences, any necessary paperwork and legal fees, and the yearly XBMC Foundation Developers Conference, where a great deal of coding and planning for the following year occurs. Donations may also be used to purchase necessary hardware and licenses for developers, along with t-shirts, stickers, and other accessories for conferences.
  • Buy Kodi merchandise: Purchasing Kodi gear helps just as much as a donation, and you get something in return! Checkout our store for Kodi branded gear. We regularly add new products so check back often.

Building

Kodi uses CMake as its building system but instructions are highly dependent on your operating system and target platform. Fortunately we've got you covered.

Acknowledgements

Kodi couldn't exist without

  • All the contributors. Big or small a change, it does make a difference.
  • All the developers that write the fantastic software and libraries that Kodi uses. We stand on the shoulders of giants.
  • Our fantastic community for the never ending support, inspiration, feedback, and for keeping us on our toes when we screw up!
  • Our sponsors. Without them, keeping a huge project like this alive would be next to impossible.

License

Kodi is GPLv2 licensed. You may use, distribute and copy it under the license terms.

Issues
  • [binary addons] move PVR addons to our binary addons buildsystem

    [binary addons] move PVR addons to our binary addons buildsystem

    These commits (and all the PVR addons in my github account) are my initial take at moving PVR addons out of the xbmc-pvr-addons repository and into our binary addons buildsystem. A few notes

    • I've only really tested compiling as I don't have any PVR setup. I only tested the pvr.demo addon which lead to the first commit.
    • I've only tested this on WIN32
    • all PVR addons in my github account (see https://github.com/Montellese?tab=repositories) are based on the repositores created by and kept in sync by @notspiff so a big thank you to him.
    • all PVR addons depend on https://github.com/Montellese/kodi-platform which in turn depends on tinyxml which are added as common dependencies to all PVR addon repositories.

    TODOs

    • [x] move kodi-platform into kodi's depends buildsystem
    • [x] test building on all platforms
    • [ ] test every PVR addon
    • [x] fix detection of OpenGL/OpenGLES2 in pvr.vdr.vnsi
    • [x] pvr.dvblink depends on libcurl
    • [ ] pvr.filmon depends on libcurl
    • [x] libjansson and cppmyth includes and libs are installed into the wrong directory
    • [x] pvr.iptvsimple depends on zlib which is downloaded from our mirrors and built using the supplied CMakeLists.txt. Unfortunately it builds shared and static libs and the builtin FindZlib.cmake provided with cmake picks up the shared lib instead of the static lib (at least on WIN32) and I haven't found a way around that yet.
    • [x] sync all PVR addons to xbmc-pvr-addons
    • [x] get the dependency handling right
    • [x] move kodi-platform to xbmc's github account
    RFC Type: Improvement Component: PVR 
    opened by Montellese 520
  • [binary addons] Add automatic dependency handling and move RSXS and some Visualizations to addons

    [binary addons] Add automatic dependency handling and move RSXS and some Visualizations to addons

    This adds automatic dependency handling for cmake based addons by using the depends folder in existing binary addons. Addons are first downloaded and extracted, then we check if the depends folder exists and handle addon deps dynamically. Tested on linux

    Additionally a few screensavers and visualizations are moved over to addons. @Montellese @jmarshallnz @notspiff ping for platform stuff and sanity checks

    Note about projectm: After sinking hours on end into trying to fix the mess that projectms buildsys is and trying to get it compiled static without unresolved symbols, I gave up at let it build dynamically. On linux libprojectm.so is copied to the addon install path.

    Type: Improvement 
    opened by wsnipex 325
  • [imx] Deinterlacing rework

    [imx] Deinterlacing rework

    This is the rework of the HW deinterlacing for IMX6 boards (see xbmc-imx6/xbmc#70). It creates a mixer threads that offloads deinterlacing to the IPU in parallel to VPU decoding and GPU rendering.

    What works:

    • Selectable deinterlacing modes: None, Auto, Force

    What does not work:

    • Double rate feature. Can be easily implemented but needs proper settings in the GUI
    • Smooth playback for HD streams which needs to be tested. The performance for my test setup increased already compared to Gotham

    This PR is for review to be integrated into the current IMX6 Codec implementation.

    Type: Improvement v15 Isengard 
    opened by smallint 204
  • [PVR] Series recordings

    [PVR] Series recordings

    This PR adds series recording support to Kodi.

    The technical concept:

    Basic concept is that PVR addons now define an arbitrary number of timer types they support, each type defining its own combination of timer type attributes (out of a set of attributes predefined by the PVR addon API).

    Kodi PVR core picks up the different types (and their attributes) using a new PVR addon API function and strictly builds up the complete timer-related logic dynamically, according to the timer attributes. Timer type information is now available at every TimerInfoTag instance.

    Essential timer attributes: Kodi distinguishes between manual (time-based) and epg-based timers. Also, there can be one-shot and repeating timers. All combinations of these attributes are allowed, e.g. "manual + one-shot" or "epg + repeating".

    Examples for other timer attributes: "supports recording priority", "supports epg search string", "supports recording folders", ...

    UI changes:

    Timer window:

    • A "Type" column has been added
    • "Scheduled time" column now handles all combinations of weekdays, and start/stop time (incl. "any time" for timer schedules) correctly.

    screenshot001

    • The timers scheduled by timer schedules (aka repeating timers) can be displayed as "children" of the timer schedule, similar to the "group items" feature of the recording window

    screenshot004

    • This behaviour can be controlled using a new (level 4) setting available in the Confluence side blade, similar to the group items feature of the recordings window.

    screenshot010

    screenshot011

    Timer settings dialog:

    • Completely rewritten from scratch, now acts completely dynamically upon the available timer types and their attributes
    • Main idea is to start creation of a new timer by selecting the appropriate timer type. Dialog content will automatically adjust itself according to the respective timer type attributes. As before, user fills in the relevant data on kicks of the new timer
    • Dialog can (like before) also used for editing existing timers
    • Couple of new/enhanced features, among them support for epg-based repeating timers, support for all weekday combinations, pre- and post-record time, ...
    • Finally, lots of bug fixes...

    screenshot006

    screenshot007

    screenshot008

    • For weekday selection, a new dialog was implemented.

    screenshot009

    Context menu actions:

    • All relevant context menu items are now displayed only if the corresponding functionality is available according to the timer type attributes. Example: Activate/deactivate timer
    • A (from my point of view very cool) new menu item "Add advanced timer" is now available if an epg entry was selected, for example in the epg grid. This opens a timer settings dialog preset to create a an epg-based series recording based on the data of the selected epg entry.

    screenshot012

    screenshot013

    Note: All this is implemented and tested against a real PVR addon (pvr.hts), not "just" pvr.demo. I consider pvr.hts as the reference implementation of this (larger) PVR addon API change. Code is currently here (https://github.com/ksooo/pvr.hts/tree/series-recording-support), PR will follow soon.

    Feedback is much appreciated!

    Type: Feature Component: PVR v16 Jarvis API change: PVR 
    opened by ksooo 190
  • Language addons

    Language addons

    Last weekend I was thining that it would be nice if we would support addons that simply provide files that could be used by internal code and/or by other addons. There would be no logic and nothing to be executed in those addons. An example use case would be image package addons that could be used by multiple skins (e.g. an image package of all studio logos). I started working on it and added a basic "resource" addon which is exposed through our VFS under a resource://path.

    Since I don't know much about skinning I decided to try another possible resource addon and came up with language addons. Every language in Kodi basically consists of a langinfo.xml and a strings.po so there are only files and no other logic. So I came up with the xbmc.resource.language addon extension point and resource.language.<language id> addons. The files of a language are available through resource://language/<language id>/<file>.

    I have adjusted the startup code (had to move addon initialization before language loading) and added some logic to handle updates coming from old configurations. I have also added reloading of language strings if the addon providing the currently used language is updated. Furthermore I have added a dialog asking the user if he wants to switch to a newly installed language (same as for skins).

    I have converted all existing languages to addons but I'm pretty sure that I messed some of them up. Furthermore I noticed that not all of the languages with a strings.po have a langinfo.xml. How does that work? Last but not least the German language also had a keyboardmap.xml file which doesn't seem to be used/referenced anywhere in our code base so I removed it.

    I have also tried to adjust the build scripts but that's completely untested right now. On win32 it's also not possible right now to choose the installed languages in the installation wizard. Furthermore Xcode will need updating.

    I have no idea how this fits into the tools used by @alanwww1 and our transifex project. Maybe with this it could become possible for language-specific teams to create an updated addon of their language themselves and submit them to the official repository to lessen the work @alanwww1 has to do on his own right now.

    TODOs:

    • [x] we need to upload all addons to a repository and integrate it into our addon repository
    • [x] I don't like having repository.xbmc.org hardcoded
    • [x] refreshing of the main addon repository doesn't work if the login dialog is enabled due to https://github.com/xbmc/xbmc/blob/master/xbmc/addons/AddonInstaller.cpp#L385
    • [ ] the OK dialog letting the user know that we had to fall back to the English language because we couldn't find the configured language doesn't always show because Confluence's Startup.xml replaces the startup window with the home window which leads to the dialog being hidden. Whether the dialog is visible or not depends on timing. The same problem applies to the migration info dialog that @Memphiz added for the XBMC -> Kodi migration.
    • [ ] we need to figure out if the windows installer properly deletes the old language directory
    • [x] android packaging still seems to include the old language files
    Type: Feature 
    opened by Montellese 188
  • Audio dsp addon handling

    Audio dsp addon handling

    Attached a audio DSP processing system over add-ons.

    This is my first version and not complete finished. Can you have a look over it and any ideas for things which must be improved or are wrong.

    The current system in steps:

    • Data is passed from CActiveAEBufferPoolResample to the DSP processing system if DSP enabled and minimum one add-on is available.
    • All Add-ons are asked about the requested stream type to find available addons and modes, e.g. 5.1 Audio not need a stereo up mix.
    • The system makes a list of master processing modes which are selectable from user.
    • The system makes also a list of pre and post processing modes which are selectable and process point moveable inside Settings->System->Audio->Audio DSP Settings
    • On data processing it goes over following steps:
      1. Input processing - Unmodified input stream and is send to all enabled add-ons for detection and error correction
      2. Input re-sample - Re sample of the input signal for the master processing, only one add-on is allowed for it.
      3. Pre processing - Used for any steps before master processing. All enabled add-ons functions are called to make this.
      4. Master processing - The main processing like, surround up mix or sound modification processes. Only one from user over menu selectable mode is allowed. Add-ons can pass multiple selectable modes to KODI. If input channel alignment on it is higher as requested output and the master mode does not perform a down mix it becomes handled from ffmpeg re sample after return of master function.
      5. Post processing - Used for any other steps like, volume correction, equalizer and much more. All enabled add-ons functions are called to make this.
      6. Output re-sample - Re sampling of the processing signal to KODI audio output processing.

    The pre and post processing modes can be selected and moved within processing chain on audio dsp settings inside Settings->System->Audio.

    Things to do or finished:

    • The first version of dsp add-on headers and the basic system is finished.
    • Things for me which missing and are to-do:
      1. Code cleanup
      2. Faults removal
      3. Create a helper documentation about a DSP add-on programming
      4. Code re check

    Addon position audiodsp1 The DSP enable position audiodsp - addon setting6 The button position to select streaming DSP settings dialogue audiodsp - addon setting4 The basic settings dialogue, separated in sub menus audiodsp - addon setting5 A add-on master mode settings dialogue audiodsp - addon setting Process chain information dialog (with CPU usage) audiodsp - addon setting2 Add-on mode process chain selection dialogue audiodsp - addon setting3

    v16 Jarvis 
    opened by AlwinEsch 172
  • CNetwork - implement IPv6

    CNetwork - implement IPv6

    rewrite of network class(es) for abstracted universal ipv6/v4 support

    Type: Improvement Rebase needed 
    opened by mk01 142
  • Controller input

    Controller input

    Here it is... the first half of RetroPlayer!

    Relavant links:

    Controller window

    This PR contains a new system for controller and keyboard input used by RetroPlayer. Games aren't included in this PR, so you'll have to use a RetroPlayer build to test the full extent of the input system. Still, the input system offers many improvements in Kodi outside of games, and lets us start collecting button map data for when games hit.

    This PR is accompanied by a binary add-on, peripheral.joystick. It warrants review alongside the PR. This add-on was created to contain all of Kodi's platform-specific joystick code and keymap data.

    Here are the blocking issues:

    • [x] Compilation on all platforms (RPi needs an #ifdef HAS_LIBUDEV around the touchscreen fix)
    • [x] Android support (thread) (thanks montellese)
    • [x] The controller window's "get more" button fails silently (report)
    • [x] Breaks some EventServer clients (Apple IR Remotes, some Yatse buttons, etc) (report)
    • [x] Erratic button presses while mapping buttons (report)
    • [x] Empty keyboard settings breaks GUI (report) (thanks montelllese)
    • [x] Missing scroll bars in controller dialog (thanks hitcher)
    • [x] Broken volume commands (report)
    • [x] Open separate PR for [guilib] fix (done: PR 8932)
    • [x] Open separate PR for [addon] changes (thanks montellese)
    • [x] Broken controller input on RPi and some linux boxes (report)
    • [x] Erratic controller behavior in GUI (report)
    • [x] Controller dialog skips down and left for some controllers (report)
    • [x] OK dialog when peripheral.joystick is not focused on opening (report) (thanks Montellese)
    • [x] Move peripheral event processing to another thread to fix hangs (report)
    • [x] Notification for add-on updates clears the controller profiles list (thanks montellese)
    • [x] Labels disappear on first install (report) (thanks montellese)
    • [x] Canceling the prompt doesn't absorb keyboard input
    • [x] Kodi doesn't fail gracefully when peripheral.joystick isn't found (report) (thanks montellese)
    • [x] Possible deadlock on shutdown (report) (thanks montellese)

    Here are the issues that aren't blocking the merge:

    • [ ] iOS Game Controller Framework support (thread)
    • [x] Broken touchscreen on RPi (report)
    • [ ] Controller button doesn't stay focused while user is mapping buttons (report)
    • [ ] Move focusing logic to CGUIViewControl (report) (skinner advice please?)
    • [ ] Incompatible with Universal Remote server (report)
    • [ ] Incompatible with iMON receiver (report)
    • [ ] Problems with accelerometers (report and linux solution)
    • [x] Controller input not ignored when Kodi is minimized (report)
    • [ ] CPeripheralAddon requires refactoring (report)
    • [x] Add "Help" button
    • [ ] Refocus controller when user ends mapping
    • [ ] The "Reset" button resets all controllers instead of asking for a specific one
    • [ ] Anomalous trigger detector misidentifies axes that are fully pressed when controller is connected
    • [ ] Erroneous drivers with no joystick name can't be mapped
    Type: Feature Component: Binary add-ons v17 Krypton Component: Settings Component: Input 
    opened by garbear 141
  • New feature: Added parameters to skin include directive ($PARAM[Name])

    New feature: Added parameters to skin include directive ($PARAM[Name])

    Skin includes have been enhanced to accept parameters and thus be able to generate dynamic content based on them. Basically, they can now act as "procedures" where needed. This can help clean up XMLs a bit, making skins much easier to read and maintain. It also allows for more component-based modular skin design.

    The syntax is as follows:

    include definition:

    <include name="MyControl1">
      <!-- parameter list with possible default values is specified here (optional) -->
      <param name="id"/>
      <param name="posx" default="120"/>
      <param name="posy" default="120"/>
      <param name="border" default="5"/>
      <param name="background">foo.png</param> <!-- alternative form -->
      <param name="color"/>
      <definition>
        <!-- include body goes here -->
        <control id="$PARAM[id]" ...>
          <posx>$PARAM[posx]</posx>
          <posy>$PARAM[posy]</posy>
          <control ...>
            ...
            <texture border="$PARAM[border]">$PARAM[background]</texture>
          </control>
          ...
          <!-- nested include call -->
          <include name="MyControl2">
            <param name="label">$INFO[Player.Title]</param>
            <param name="color" value="$PARAM[color]"/> <!-- parameter forwarding -->
          </include>
          ...
        </control>
        ...
      </definition>
    </include>
    

    include call:

      <include file="MyControls.xml" name="MyControl1">
        <param name="id" value="60"/>
        <param name="posx" value="225"/>
        <param name="posy" value="150"/>
        <param name="color" value="white"/>
      </include>
    

    Rules:

    • Parameter list is specified using <param> tags in both include calls and definitions.
    • Include definition body is enclosed within <definition> tag.
    • Default values for parameters can be specified within include definition and are used as replacement when parameters are not passed in the include call
    • Parameters without default values in include definitions are specified for better readability and documentation purposes only, but are otherwise not mandatory and can be omitted.
    • If there are no <param> tags in include definition, <definition> tag can be omitted too.
    • Concrete arguments are specified within include call tag
    • Actual arguments are a combination of these two, with passed arguments having a higher priority over default ones
    • Parameter references of the form $PARAM[ParamName] are replaced with actual arguments within include definition body, inside both tag values and attributes
    • There can be one or more parameter references specified within a single tag/attribute value, possibly in combination with other characters (e.g. <param name="debug" value="x:$PARAM[x]; y:$PARAM[y]"/>)
    • Parameter references are resolved before everything else ($INFO labels, $LOCALIZE, etc.), so these can be passed as arguments too
    • Parameter references that refer to missing/undefined parameters are replaced with empty strings; one exception to this rule is when forwarding a missing parameter of the form <param name="..." value="$PARAM[MissingParamName]"/> from enclosing include to the nested include, where this parameter, which would normally be expanded to "", won't be passed at all, allowing any default value from the nested include to be correctly picked up and not overriden by ""
    • Extra parameters in include call that are passed but not referenced anywhere within include definition are ignored
    • Incomplete parameter references (without closing ']') are logged as errors and left as is, rather than resolved to empty strings

    This feature was proposed and discussed in more detail here: http://forum.xbmc.org/showthread.php?tid=190135. It requires a change in Wiki documentation which I can help with if it gets accepted.

    EDIT: Originally proposed syntax is given below. Together with the discussion that follows it, it shows the full evolution of the feature for any future reference. This syntax is NOT included in Kodi.

    include definition:

    <!-- default parameter values are specified here -->
    <include name="MyControl1" p:posx="120" p:posy="120" p:border="5" p:background="foo.png">
      <control id="$PARAM[id]" ...>
        <posx>$PARAM[posx]</posx>
        <posy>$PARAM[posy]</posy>
        <control ...>
          ...
          <texture border="$PARAM[border]">$PARAM[background]</texture>
        </control>
        ...
        <!-- nested include call -->
        <include p:label="$INFO[Player.Title]" p:color="$PARAM[color]">MyControl2</include>
        ...
      </control>
      ...
    </include>
    

    include call:

      <include file="MyControls.xml" p:id="60" p:posx="225" p:posy="150" p:color="white">MyControl1</include>
    
    Type: Feature v15 Isengard API change: GUI Component: Skin 
    opened by dslijepcevic 131
  • [add-ons/settings] migrate add-on settings to settings library

    [add-ons/settings] migrate add-on settings to settings library

    Description

    So this is it. I've been "dreaming" of this final step ever since I worked on the original settings rework in core but it turned out to be much more complicated than expected which is also why it took so long. This PR introduces (almost) all the necessary bits to be able to use the same settings system for add-ons that we already in core. Furthermore it contains a backwards compatibility layer which reads in old settings definitions (and values) and translates those into settings from the new system. After this PR settings will always be saved in the same format as guisettings.xml but it can read the settings definition either from the old add-on settings format or from the "new" core settings system format.

    Since I'm not that much of an add-on user myself and since I've never written an add-on myself I'm pretty sure I missed a few things in the backwards compatibility layer. So it would be greatly appreciated if people with more experience in this area could give this a try. But beware once Kodi has written the setting values in the new format you can't go back to the old format without losing all your add-on settings. So best make a backup of your add-on data before giving this a try.

    There are a few parts that are known not to be backwards compatible but I've tried to add log messages in those places so that it becomes obvious. I hope that those cases are edge cases that can live without backwards compatibility but who knows.

    There are also parts that I wasn't able to test like binary add-ons defining settings through the binary add-on API since I don't know if and which add-on is using this at all.

    In the end the major benefit is that GUIDialogAddonSettings has become very simple because it can derive from the existing settings related base classes. The major part of the work is in CAddonSettings which also contains the backwards compatibility layer which we can hopefully drop someday (a few releases into the future).

    I'm not sure if we want to "mark" the old add-on settings approach as deprecated to try and get add-ons to adopt to the new approach or not.

    Some (basically the first 25) of the commits could go into a separate PR (as I've already done with a few fixes before) but since they didn't bring any real benefit to the existing code I didn't do that yet. If someone would like me to do that to make reviewing easier I'm fine with that. Just let me know.

    Part of this work also overlaps with my media importing work (CSettingsBase et al.) and should make things a bit easier there as well code-wise.

    How Has This Been Tested?

    Locally by installing some add-ons, opening their add-on settings and comparing the result to before.

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] New feature (non-breaking change which adds functionality)
    • [x] Breaking change (fix or feature that would cause existing functionality to change)

    Checklist:

    • [x] My code follows the Code guidelines of this project
    • [x] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [x] I have read the CONTRIBUTING document
    • [ ] I have added tests to cover my change
    • [x] All new and existing tests passed
    Component: Settings Component: Add-ons v18 Leia 
    opened by Montellese 127
  • [tools/depends][target] pythonmodule-pil update sed replace for macos conformance

    [tools/depends][target] pythonmodule-pil update sed replace for macos conformance

    Description

    Allow build on macos host

    Motivation and context

    Android build on macos host

    How has this been tested?

    Build android on osx

    What is the effect on users?

    N/A

    Screenshots (if appropriate):

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [x] Improvement (non-breaking change which improves existing functionality)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [x] My code follows the Code Guidelines of this project
    • [ ] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [x] I have read the Contributing document
    • [ ] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Platform: Android Component: Depends v20 Nexus 
    opened by fuzzard 0
  • Some MusicBrainz identifiers not exposed via Python API as expected

    Some MusicBrainz identifiers not exposed via Python API as expected

    Bug report

    Describe the bug

    Here is a clear and concise description of what the problem is:

    Even though MusicBrainz Release and Release Group MBIDs are in both file tags and in Kodi’s database, they are not returned when using the xbmc.Player.getMusicInfoTag().getMusicBrainzAlbumID() and .getMusicBrainzReleaseGroupID() methods. .getMusicBrainzAlbumArtistID() also just returns an empty list.

    Expected Behavior

    Here is a clear and concise description of what was expected to happen:

    I expected .getMusicBrainzAlbumID() and .getMusicBrainzReleaseGroupID() to return strings with a UUID/MBID, and .getMusicBrainzAlbumArtistID() to return a list of at least one UUID/MBID string.

    Actual Behavior

    .getMusicBrainzAlbumID() and .getMusicBrainzReleaseGroupID() returned empty strings, and .getMusicBrainzAlbumArtistID() returned an empty list.

    Possible Fix

    To Reproduce

    Steps to reproduce the behavior:

    1. Run code similar to https://gitlab.com/Freso/service.listenbrainz/-/blob/c45d467245a4b4d09e7f334f4cc1d797e268c289/listener.py#L267-268 to inspect the output.

    Debuglog

    The debuglog can be found here: https://paste.kodi.tv/etipaliwul.kodi

    Additional context or screenshots (if appropriate)

    Here is some additional context or explanation that might help:

    I probably missed something in my PR for these methods when I implemented them in Python: https://github.com/xbmc/xbmc/pull/15849 – alternatively, maybe the C functions are not working, which means that Python is trying to get values from the C API that the C API itself cannot currently get?

    Tracking the issue for service.listenbrainz at https://gitlab.com/Freso/service.listenbrainz/-/issues/29

    Your Environment

    Used Operating system:

    • [ ] Android

    • [ ] iOS

    • [ ] tvOS

    • [x] Linux

    • [ ] OSX

    • [ ] Windows

    • [ ] Windows UWP

    • Operating system version/name: Arch Linux

    • Kodi version: 19.3

    note: Once the issue is made we require you to update it with new information or Kodi versions should that be required. Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

    Triage: Needed 
    opened by Freso 3
  • Audio stutter on win11 due to broken Directsound

    Audio stutter on win11 due to broken Directsound

    Bug report

    Describe the bug

    After moving from win10 to win11, I can no longer enjoy videos on kodi. Audio stutters all the way including UI sound. A workaround I found is switching the audio backend to WASAPI, where Directsound, the default choice, seems to be broken. Both the UWP version from M$ store and the .exe installer suffer from the same problem.

    Expected Behavior

    Audio plays normally.

    Actual Behavior

    Both UI sound and video sound stutter all the way.

    Possible Fix

    No idea.

    To Reproduce

    Steps to reproduce the behavior:

    1. Fresh install Kodi 19.3 on a win11 machine.
    2. Play a random video or use arrow keys to browse the menus to trigger UI sound.

    Debuglog

    The debuglog can be found here, which is full of:

    WARNING <general>: CWin32DirectSound::GetSpace - buffer underrun - W:16248, P:4294965000, O:384.
    

    Full log: https://fars.ee/nYT6.log (captured from a fresh UWP install)

    Your Environment

    Used Operating system:

    • [ ] Android

    • [ ] iOS

    • [ ] tvOS

    • [ ] Linux

    • [ ] OSX

    • [X] Windows

    • [X] Windows UWP

    • Operating system version/name: Windows 11 Home 21H2 22000.348

    • Device: Surface Pro 7

    • Kodi version: 19.3

    note: Once the issue is made we require you to update it with new information or Kodi versions should that be required. Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

    opened by MoetaYuko 0
  • Android fixups/minors

    Android fixups/minors

    Description

    Some minor fixes for use when building against current SDK/NDK (eg 31/23 right now)

    Motivation and context

    Updating android build instructions for a macos host. In addition, get any android host to be able to build against latest SDK/NDK's

    How has this been tested?

    Build and runtime tested aarch64 android built on Apple Silicon based host. Requires a few additional patches. WIP branch can be seen at https://github.com/fuzzard/xbmc/commits/macosarm_android

    What is the effect on users?

    N/A

    Screenshots (if appropriate):

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [x] Improvement (non-breaking change which improves existing functionality)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [x] My code follows the Code Guidelines of this project
    • [ ] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [x] I have read the Contributing document
    • [ ] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Platform: Android Component: Depends v20 Nexus 
    opened by fuzzard 1
  • GLUtils: add helper method GetChannelFromARGB to replace macros

    GLUtils: add helper method GetChannelFromARGB to replace macros

    This removes the GET_X macros defined in the system_gl.h header file.

    This new method combines the logic from the four macros. I figured GLUtils was the best place for this as it's used only in GL/ES code (as opposed to putting it in ColorUtils).

    It's a bit verbose with all the namespaces but I'm ok with that.

    Type: Cleanup Type: Improvement Component: GL rendering Component: GLES rendering v20 Nexus 
    opened by lrusak 1
  • CAppParamParser cleanup and improvment

    CAppParamParser cleanup and improvment

    This splits out the linux specific options from CAppParamParser. I wanted to do this to make it easier to read and extend.

    I've also made some other improvements:

    1. Using raw string literals for the text. This is much more readable (IMO) than the printf statements with new line and tab characters.
    2. Using proper setters and getters for the private members.

    This also fixes (what I think was a bug) the version string. before:

    $ ./kodi.bin --version
    20.0-ALPHA1 (19.90.101) Git:20211104-f8d5f01074-dirty Media Center Kodi
    Copyright (C) 2005-2021 Team Kodi - http://kodi.tv
    

    after:

    $ ./kodi.bin --version
    Kodi Media Center 20.0-ALPHA1 (19.90.101) Git:20211120-d7727f99ee
    Copyright (C) 2005-2021 Team Kodi - http://kodi.tv
    

    Notice that the Kodi Media Center, then the version string. I'm not sure if what is contained in the before version is actually desired or not.

    Also, the help text looks like this on Linux now:

    $ ./kodi.bin --help
    Usage: kodi [OPTION]... [FILE]...
    
    Arguments:
      -fs                   Runs Kodi in full screen
      --standalone          Kodi runs in a stand alone environment without a window
                            manager and supporting applications. For example, that
                            enables network settings.
      -p or --portable      Kodi will look for configurations in install folder instead of ~/.kodi
      --debug               Enable debug logging
      --version             Print version information
      --test                Enable test mode. [FILE] required.
      --settings=<filename> Loads specified file after advancedsettings.xml replacing any settings specified
                            specified file must exist in special://xbmc/system/
    
    Linux Specific Arguments:
      --windowing=<system>  Select which windowing method to use.
                              Available window systems are: x11, wayland, gbm
      --logging=<target>    Select which log target to use (log file will always be used in conjunction).
                              Available log targets are: console
    
    Type: Cleanup Type: Improvement Platform: Linux Component: System v20 Nexus 
    opened by lrusak 3
  • [fonts] add away to use two TTF fonts

    [fonts] add away to use two TTF fonts

    Description

    This adds a support to load two independent TTF fonts, background is to get a missing character from the second font.

    It mainly refers to having supported skins and their fonts in all languages.

    The following languages ​​cannot currently be displayed:

    • Amharic
    • Arabic (but works in Arial)
    • Burmese
    • Chinese (Simple) (but works in Arial)
    • Chinese (Traditional) (but works in Arial)
    • Hindi (Devanagiri)
    • Japanese (but works in Arial)
    • Kannada
    • Korean (but works in Arial)
    • Malayalam
    • Persian (but works in Arial)
    • Persian (Iran) (but works in Arial)
    • Sinhala
    • Tamil (India)
    • Telugu
    • Thai

    The way is not the best, but it would be a solution.

    The best solution would be to lay down a table in Kodi in which UTF8 character code series is assigned to a font and thus to select each individual character in the appropriate font (similar to Pango or how Chromium does it for websites). However, Kodi's font system in the current style cannot be implemented in this way and would need a complete rebuild of the system (as far as I know).

    The first commit renames a part, I was really confused how the name was used before because the same name (only with case difference) was used twice for different things.

    Motivation and context

    To become some issues fixed.

    Not sure if this way acceptable, if not, then we can close request.

    How has this been tested?

    What is the effect on users?

    Screenshots (if appropriate):

    Bildschirmfoto vom 2021-11-19 21-23-39 Bildschirmfoto vom 2021-11-20 00-24-38 Bildschirmfoto vom 2021-11-21 02-28-30 Bildschirmfoto vom 2021-11-21 02-30-08

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [ ] Improvement (non-breaking change which improves existing functionality)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [ ] My code follows the Code Guidelines of this project
    • [ ] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [ ] I have read the Contributing document
    • [ ] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Type: Improvement Component: Skin v20 Nexus 
    opened by AlwinEsch 11
  • [AEsinkAUDIOTRACK] Fix TrueHD buffer size/frame duration IEC and RAW

    [AEsinkAUDIOTRACK] Fix TrueHD buffer size/frame duration IEC and RAW

    Description

    • Fixes no audio output using Android IEC packer (RAW) with TrueHD.
    • Fixes micro-stuttering using Kodi IEC packer with TrueHD.

    Motivation and context

    https://github.com/xbmc/xbmc/pull/20339 has produced some regressions on Android due the way AEsinkAUDIOTRACK handles HD formats and because it is the only platform that uses the RAW packer.

    NOTE: This PR only addresses the two issues mentioned in description. The rest of micro stuttering issues with other audio formats (AC3, DTS, DTS-MA, E-AC3) are resolved in another PR already merged: https://github.com/xbmc/xbmc/pull/20127

    How has this been tested?

    Runtime tested on Shield TV Pro 2019

    What is the effect on users?

    See Description

    Types of change

    • [X] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [ ] Improvement (non-breaking change which improves existing functionality)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [X] My code follows the Code Guidelines of this project
    • [ ] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [X] I have read the Contributing document
    • [ ] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Type: Fix Platform: Android Component: Audio v20 Nexus 
    opened by thexai 4
  • [AdvancedSettings] add new cleanstrings

    [AdvancedSettings] add new cleanstrings

    Description

    New cleanstrings added and re-organized them in alphabetical order so it's easier to find what is missing or not

    Motivation and context

    As we already strings like x264 or 1080p we thought it might be useful to add other resolutions, audio standards, video codecs as well

    How has this been tested?

    What is the effect on users?

    Better scraping experience if filenames contain video codecs or resolution-/media-flags.

    Screenshots (if appropriate):

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [x] Improvement (non-breaking change which improves existing functionality)
    • [ ] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [x] My code follows the Code Guidelines of this project
    • [x] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [ ] I have read the Contributing document
    • [ ] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Type: Improvement Component: Settings Component: Content v20 Nexus 
    opened by DaVukovic 4
  • [Subtitles] Add support to OpenType font type (OTF)

    [Subtitles] Add support to OpenType font type (OTF)

    Description

    Add support to use OpenType font type (.otf) with subtitles (Libass support it without problems), for completeness i have also performed a test of loading (in forced way) OTF fonts with the Skin to check if they are correctly loaded with the GUI, see screenshots.

    Motivation and context

    Fix issue #19399

    How has this been tested?

    I have tried to set as font two type of OTF fonts: immagine as subtitle font and as Skin font by replacing the default TTF arial font

    What is the effect on users?

    Can use OTF fonts with subtitles

    Screenshots (if appropriate):

    Subtitles: immagine Skin: immagine

    Types of change

    • [ ] Bug fix (non-breaking change which fixes an issue)
    • [ ] Clean up (non-breaking change which removes non-working, unmaintained functionality)
    • [ ] Improvement (non-breaking change which improves existing functionality)
    • [x] New feature (non-breaking change which adds functionality)
    • [ ] Breaking change (fix or feature that will cause existing functionality to change)
    • [ ] Cosmetic change (non-breaking change that doesn't touch code)
    • [ ] None of the above (please explain below)

    Checklist:

    • [x] My code follows the Code Guidelines of this project
    • [ ] My change requires a change to the documentation, either Doxygen or wiki
    • [ ] I have updated the documentation accordingly
    • [x] I have read the Contributing document
    • [x] I have added tests to cover my change
    • [ ] All new and existing tests passed
    Type: Feature v20 Nexus Component: Subtitles 
    opened by CastagnaIT 0
Releases(19.3-Matrix)
Rygel is a home media solution that allows you to easily share audio, video and pictures, and control of media player on your home network

Rygel is a home media solution that allows you to easily share audio, video and pictures, and control of media player on your home network. In technical terms it is both a UPnP AV MediaServer and MediaRenderer implemented through a plug-in mechanism. Interoperability with other devices in the market is achieved by conformance to very strict requirements of DLNA and on the fly conversion of media to format that client devices are capable of handling.

GNOME Github Mirror 51 Nov 30, 2021
UPnP Media Server for 2021: Stream your digital media through your home network and consume it on all kinds of UPnP supporting devices 📱💻📺

Gerbera - UPnP Media Server Gerbera is a UPnP media server which allows you to stream your digital media through your home network and consume it on a

Gerbera 831 Nov 30, 2021
ZoneMinder is a free, open source Closed-circuit television software application developed for Linux which supports IP, USB and Analog cameras.

ZoneMinder All documentation for ZoneMinder is now online at https://zoneminder.readthedocs.org Overview ZoneMinder is an integrated set of applicatio

null 3.4k Nov 24, 2021
VLC is a popular libre and open source media player and multimedia engine,

VLC is a popular libre and open source media player and multimedia engine, used by a large number of individuals, professionals, companies and institutions. Using open source technologies and libraries, VLC has been ported to most computing platforms, including GNU/Linux, Windows, Mac OS X, BSD, iOS and Android.

VideoLAN 8.2k Nov 26, 2021
The Free Software Media System

Jellyfin The Free Software Media System Jellyfin is a Free Software Media System that puts you in control of managing and streaming your media. It is

Jellyfin 12.4k Nov 23, 2021
A fully responsive interface to manage all your favorite software on your Htpc.

Hellowlol HTPC Manager fork ===== A python based web application to manage the software on your HTPC. HTPC Manager combines all your favorite software

Steffen Fredriksen 355 Nov 18, 2021
A fully responsive interface to manage all your favorite software on your Htpc.

HTPC Manager A python based web application to manage the software on your Htpc. Htpc Manager combines all your favorite software into one slick inter

Styxit 536 Nov 23, 2021
The easiest music streaming server available

mStream Music mStream is a personal music streaming server. You can use mStream to stream your music from your home computer to any device, anywhere.

Paul 1.7k Nov 27, 2021
Beautiful web-based music player

Stretto An open source web-based music player Go to Stretto, or if you would like to host it yourself, scroll down to the developer instructions. How

Benjamin Kaiser 555 Nov 17, 2021
Airsonic is a free, web-based media streamer, providing ubiquitous access to your music.

Airsonic is a free, web-based media streamer, providing ubiquitous access to your music. Use it to share your music with friends, or to listen to your own music while at work. You can stream to multiple players simultaneously, for instance to one player in your kitchen and another in your living room.

null 1.9k Nov 25, 2021
Music player server with a web-based user interface.

Music player server with a web-based user interface. Run it on a server connected to some speakers in your home or office. Guests can control the musi

Andrew Kelley 1.8k Nov 20, 2021
Lightweight Music Server. Access your self-hosted music using a web interface.

LMS - Lightweight Music Server LMS is a self-hosted music streaming software: access your music collection from anywhere using a web interface! A demo

Emeric POUPON 493 Nov 28, 2021
Python library which provides a client interface for the Music Player Daemon.

python-mpd2 python-mpd2 is a Python library which provides a client interface for the Music Player Daemon. Difference with python-mpd python-mpd2 is a

Jörg Thalheim 312 Nov 26, 2021
Stream your own music collection to all your devices! The easy to use free and open-source music streaming server.

CherryMusic CherryMusic is a music streaming server based on CherryPy and jPlayer. It plays the music inside your PC, smartphone, tablet, toaster or w

Tom Wallroth 1k Nov 23, 2021
Icecast is a streaming media server which currently supports WebM and Ogg streaming including the Opus, Vorbis and Theora codecs.

Icecast is a streaming media server which currently supports WebM and Ogg streaming including the Opus, Vorbis and Theora codecs. Also Icecast can handle other streams like MP3/AAC/NSV in legacy mode, but this is not officially supported.

Xiph.Org Foundation 345 Nov 23, 2021
Node.JS Server and JavaScript/HTML Client for synchronizing online media

CyTube CyTube is a project I started in early 2013 as a hobby project to build my own clone of synchtube.com (which shut down in March 2013). The basi

Calvin Montgomery 1.2k Dec 1, 2021
OBPlayer is a stable and secure UNIX-based media streaming playout application that can operate as a standalone player or controlled over a network by a managing OBServer instance.

OBPlayer is a stable and secure UNIX-based media streaming playout application that can operate as a standalone player or controlled over a network by a managing OBServer instance. It can be installed remotely at a transmitter site, in the studio or as a virtual headless process on a server.

OpenBroadcaster 66 Nov 11, 2021
Flumotion is a streaming media server based on GStreamer and Twisted.

This is the first public development series of Flumotion. It will probably still contain bugs, be difficult to install (since you need recent dependencies), and cause you some headaches.

Flumotion 23 May 12, 2021