Kodi is an award-winning free and open source software media player and entertainment hub for digital media

Kodi Logo

websitedocscommunityadd-ons

License 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, skins etc. 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.

Comments
  • [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
  • [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.

  • [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.

  • [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!

  • 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
  • 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

  • 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
  • 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>
    
  • [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
  • enable dirty regions for full screen video

    enable dirty regions for full screen video

    Moves video rendering (fullscreen) from application to GUIWindowFullScreen. By doing this dirty regions work on fullscreen mode and the platform has separate layers for video and ui.

    @popcornmix iirc you still need some options to limit fps of gui, right?

  • native resolution ( disable upscaling ) option

    native resolution ( disable upscaling ) option

    http://forum.xbmc.org/showthread.php?tid=64139&pid=1131505#pid1131505

    I spent few hours to dig into it and the results are promising. I'm pretty fresh to xbmc though, so maybe there is better way to deal with it. Anyway, what you need to run native resolution:

    • apply the provided patch
    • set in your advancedsettings.xml following variable in < video > section:
        <video>
            <upscalemode>1</upscalemode>      <!-- upscalemode: 0-default, 1-native scaling -->
        </video>
    
    • set your receiver to upscaling mode - upscale source to maximum display resolution (1080p in my case)

    How it works:

    • the GUI works with maximum resolution
    • when the player is spawned it reads the source dimension and sets the renderer to the lowest supported resolution which is the best match for the source resolution
    • the movie is played with lowest acceptable resolution and is upscaled by the receiver to 1080p
    • when the playback stops, the xbmc GUI is back to default resolution (1080p for me)

    Here are few examples, where USER = default screen resolution NATIVE = movie resolution ADJUST2 = final xbmc resolution for playback

    
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 1920x1080
        NOTICE: Display resolution ADJUST2 : default: 1920x1080 @ 24.00Hz (17)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 1280x720
        NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 720x304
        NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 608x336
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 640x256
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 640x272
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 720x392
        NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 608x256
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 640x352
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 624x224
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 1280x544
        NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
        .
        NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
        NOTICE: Searching for NATIVE resolution: 624x352
        NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    

    I have to say that results are surprisingly good. I'm using receiver with Marvell Qdeo chip and it is doing great job, the picture is visible better than when xbmc is upscaling directly to 1080p. Well, you need to try yourself to judge.

    The function used to find the closest resolution match is very simple, perhaps it might be improved. For now it tries to find the lowest resolution which is equal or higher than source resolution and tries to keep as close as possible to original refresh rate for the display.

  • [docs] Remove typo in playlist python docs

    [docs] Remove typo in playlist python docs

    Description

    I noticed an extra n in this section while debugging an issue with one of my addons.

    Motivation and context

    Improve docs

    How has this been tested?

    N/A

    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)
    • [ ] 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)
    • [x] 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
    • [x] 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
  • [settings] Introduce new string id for BackgroundType::NONE …

    [settings] Introduce new string id for BackgroundType::NONE …

    …as the English word 'None' needs translation to different words for some languages. Example: In German, 'none' can be 'kein', 'keiner', keine', depending on the context.

    @da-anda changed string is used in subtitle settings to indicate that no background type shall be used, which is "None" in English, corresponding string id is 231 which exists since a long time and got reused here. It is translated to "Keine" in German. This translation fits for the other places this id was used before, but for the background type this needs to read "Keiner" in German, thus we need to introduce another string id with the English text "None", that will be translated to German "Keiner".

    231 English "None" => German "Keine" 39188 English "None" => German "Keiner" (because of "Der Typ")

  • Nightly 6/22/22 19.4 Broke file Manager connecting to Web server, nightly 6/8/22 works fine.

    Nightly 6/22/22 19.4 Broke file Manager connecting to Web server, nightly 6/8/22 works fine.

    Bug report

    Describe the bug

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

    Bug report Used nightly June 22 2022 Added a path to my web server Apache 2.4 PHP 7.4 with http://mywebsite.org/repo and it says remote share couldn't connect to network sharecontent. If I go back to nightly dated June 8 2022 it works fine.

    Expected Behavior

    It should have shown files in my repo folder.:

    Actual Behavior

    it says remote share couldn't connect to network sharecontent

    Possible Fix

    Went back to nightly June 8 2022

    To Reproduce

    Steps to reproduce the behavior:

    1. Installed the latest Nightly.
    2. Went back to older nightly
    3. Did this several times, also checked my paths several times.

    Debuglog

    The debuglog can be found here:

    Screenshots

    Here are some links or screenshots to help explain the problem:

    Additional context or screenshots (if appropriate)

    Here is some additional context or explanation that might help:

    Your Environment

    Used Operating system:

    • [ ] Android

    • [ ] iOS

    • [ ] tvOS

    • [ ] Linux

    • [ ] OSX

    • [ ] Windows

    • [ ] Windows UWP

    • Operating system version/name:

    • Kodi version:

    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.

  • [Cmake] enable_internal_cec

    [Cmake] enable_internal_cec

    Description

    Allow building cec via core cmake project, and default build for all platforms (except linux/freebsd system builds)

    Motivation and context

    More depends being built via cmake Update windows libs to build from source (and more current versions in line with tools/depends platforms)

    How has this been tested?

    Build win/apple/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
  • [addons] fix update detection based on „official/any repo“ setting

    [addons] fix update detection based on „official/any repo“ setting

    Description

    Backport https://github.com/xbmc/xbmc/pull/21581 Closes https://github.com/xbmc/xbmc/issues/21572

    1. CAddonRepos::FindAddonAndCheckForUpdate() return false if checked add-on is found and up to date
    2. disable add-on installation path check

    Types of change

    • [X] Bug fix (non-breaking change which fixes an issue)

    Checklist:

  • Kodi:Windows10: Addon YeloTV : It works only the first  time after installation kodi

    Kodi:Windows10: Addon YeloTV : It works only the first time after installation kodi

    Bug report

    2022-06-19 17:29:34.859 T:13088 ERROR : AddOnLog: inputstream.adaptive: License update not successful (no keys) 2022-06-19 17:29:34.983 T:13088 ERROR : AddOnLog: inputstream.adaptive: Initialize failed (SingleSampleDecrypter) 2022-06-19 17:29:34.989 T:13088 ERROR : CVideoPlayer::OpenInputStream - error opening [plugin://plugin.video.yelo/play/id/2behd]

    Describe the bug

    I've installed Kodi version 19.4, installed addon YeloPlay 1.0.2. I've selected video addon YeloPlay via the navigation of kodi; and then selected TV channel VTMhd, this worked fine, no problem. I've closed the channel and then selected TV channel 2behd, I got the message on the screen "Playback failed", I retried with VTMhd and got the same error. It does not work again. This happened in a moment of minutes between the first time (when it worked) and the other tries (when it did not work anymore).

    I had the same behavior with Kodi version 19.3.

    Expected Behavior

    It worked just after the installation, just one time, so it should work also for the next times. I did not any installation or configuration between.

    Actual Behavior

    Kodi gave an error on his log : "License update not successful" and "Initialize failed" and "error opening plugin" Closing and restarting Kodi did not solved the issue. Only a full de-install and re-install of kodi solved the issue once.

    Possible Fix

    Maybe there is a difference in the code between the first time and the next times? Caching? Temp-files?

    To Reproduce

    Steps to reproduce the behavior:

    1. select add on Yelo Play
    2. select channel VTMhd
    3. close the channel
    4. select again channel VTMhd or another

    Debuglog

    see attached files below.

    Screenshots

    image

    Additional context or screenshots (if appropriate)

    no remarks

    Your Environment

    Used Operating system:

    • [ ] Windows

    • Operating system version/name:

    • image

    • Kodi version: 19.3 and 19.2

    Thanks for your help, if you need more info don't hesitate to contact me. If I can help, let me know.

    kodi.log_license_update.txt

🎥 mpv is a free (as in freedom) media player for the command line.
🎥 mpv is a free (as in freedom) media player for the command line.

mpv is a free (as in freedom) media player for the command line. It supports a wide variety of media file formats, audio and video codecs, and subtitle types.

Jun 21, 2022
theora-player is an embeddable theora video player C++ library based on the libtheora sample. It has no audio support at this moment.

theora-player Description theora-player is an embeddable theora video player C++ library based on the libtheora sample. It has no audio support at thi

Oct 14, 2021
TIP (translate it, please) is a plugin for VLC media player that helps you to study languages by watching videos.

vlc-tip-plugin TIP (translate it, please) is a plugin for VLC media player that helps you to study languages by watching videos. Features The plugin a

May 2, 2022
Jellyfin Desktop Client based on Plex Media Player
Jellyfin Desktop Client based on Plex Media Player

Desktop client using jellyfin-web with embedded MPV player. Supports Windows, Mac OS, and Linux. Media plays within the same window using the jellyfin-web interface unlike Jellyfin Desktop. Supports audio passthrough. Based on Plex Media Player.

Jun 19, 2022
A clone of Media Player Classic reimplemented in Qt.
A clone of Media Player Classic reimplemented in Qt.

Media Player Classic Qute Theater A clone of Media Player Classic reimplemented in Qt. Media Player Classic Home Cinema (mpc-hc) is considered by many

Jun 18, 2022
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support
An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support

Vita-Media-Player An Open Source PSVita/TV MP4 player with 1080p playback and subtitle support 1080i output supported on the PSTV natively and on the

May 28, 2022
Official repository of the ISO Base Media File Format Reference Software

ISO Base Media File Format (ISOBMFF) This repository is the official repository for the ISO Base Media File Format Reference Software. The ISO base me

May 26, 2022
OpenShot Video Library (libopenshot) is a free, open-source C++ library dedicated to delivering high quality video editing, animation, and playback solutions to the world

OpenShot Video Library (libopenshot) is a free, open-source C++ library dedicated to delivering high quality video editing, animation, and playback solutions to the world

Jun 21, 2022
Shotcut - a free, open source, cross-platform video editor
 Shotcut - a free, open source, cross-platform video editor

cross-platform (Qt), open-source (GPLv3) video editor

Jun 23, 2022
Video player for 3ds
Video player for 3ds

Video player for 3DS Patch note v1.0.1 Added allow skip frames option v1.0.0 Initial release Summary Video player for 3DS Performance 256x144(144p)@30

Jun 10, 2022
A simple but powerful multimedia player library designed for Qt Quick.

QtMediaPlayer A simple but powerful multimedia player library designed for Qt Quick. Features Full-featured multimedia player Cross-platform: support

Apr 21, 2022
GB Studio Extended Nominal Player Adaptation/Interface
GB Studio Extended Nominal Player Adaptation/Interface

gbsenpai gbsenpai - GB Studio Extended Nominal Player Adaptation/Interface - is a project to port the GB Studio player to additional, non-GB/GBC platf

Jun 13, 2022
Yakuza Arcade Machine Player - play Virtua Fighter 5: Final Showdown on PC, using Yakuza 6 files.
Yakuza Arcade Machine Player - play Virtua Fighter 5: Final Showdown on PC, using Yakuza 6 files.

Yakuza Arcade Machines Player Yakuza Arcade Machines Player is a launcher that allows you to run Virtua Fighter 5: Final Showdown, standalone and nati

Apr 24, 2022
🤟Super fast H.264/H.265 FLV player
🤟Super fast H.264/H.265 FLV player

??Super fast H.264/H.265 FLV player

Jun 21, 2022
simple mp4 player based on rockchip rv1109 platform

mp4player RV1109平台上实现一个简单的 mp4 播放器,主要是本人使用的开发板QT无法播放mp4,应该是没有编译qst所致,因而想利用rockchip平台自有的 功能实现一个简单的播放器。 base目录包含一些基础框架实现,包含信号,线程,时间等,线程和消息泵的实现非常非常简单,因而不

Feb 22, 2022
Implement a universal video player based on FFmpeg

qiaopcmusic 实现一个万能视频播放器 添加依赖方式: To get a Git project into your build: Step 1. Add the JitPack repository to your build file Add it in your root build.

Oct 15, 2021
FFmpeg powered audio player in node.js

sange FFmpeg powered audio player in node.js prerequisites node.js cmake sudo apt install cmake c++ compiler sudo apt install g++ gcc ffmpeg sudo apt

May 2, 2022
Poppy Music Player

Poppy Music Player poppy is a simple music player that is controlled by process signals. Build Before anything: meson setup build cd build Compiling n

Apr 26, 2022
RTSP Wasm Player
RTSP Wasm Player

RTSP Wasm Player Overview # RTSP WebSocket Proxy RTSP/Webcam/File > FFmpeg open > Packets > WebSocket # WS Wasm Player WebSocket > Packets > Wasm FFm

Jun 8, 2022