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

    opened by FernetMenta 124
  • 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.

    Type: Feature 
    opened by adam-aph 119
  • AESinkAudioTrack: Document progress

    AESinkAudioTrack: Document progress

    These are the results of the work I was able to do during christmas break. Seeking with RAW works way better. Kodi complexity was highly reduced and sleep workarounds as well.

    Someone needs to bring it forward. Best someone with a Shield and other devices.

    I want to park that here for reference as everyday job starts again.

    opened by fritsch 0
  • VideoPlayerCodec: Stop dividing by zero

    VideoPlayerCodec: Stop dividing by zero

    When parsing a file failed so that needed fields, in our case frameSize are not available a guess work like with m_channels or m_samplerate does not help. Therefore fail early.

    Fixes: #22378

    Type: Fix Backport: Needed Component: Video v21 Omega Security 
    opened by fritsch 0
  • [PVR] Quick fix/workaround for empty channel/guide window when used a…

    [PVR] Quick fix/workaround for empty channel/guide window when used a…

    …s startup window due to missing window content refresh after PVR Manager started.

    Backport of #22389

    @phunkyfish please review. Regression risk is low to zero.

    Type: Fix Component: PVR Type: Backport v20 Nexus 
    opened by ksooo 0
  • [PVR] Quick fix/workaround for empty channel/guide window when used a…

    [PVR] Quick fix/workaround for empty channel/guide window when used a…

    …s startup window due to missing window content refresh after PVR Manager started.

    Supersedes #22374.

    This is a quick fix with low regression risk. The root cause of the problem is identified but fix is rather high effort. Therefore we will go with a quick fix for now and I put the real fix on my todo list.

    Root cause: When used as a startup window, loading window content must be deferred until the component responsible to deliver the data for the window is fully initialized. PVR startup is async. This logic is currently (maybe always was broken). Details are discussed in #22374.

    Runtime-tested by me and @emveepee

    @phunkyfish please review.

    Type: Fix Component: PVR Backport: Done v21 Omega 
    opened by ksooo 0
  • InfoTagVideo.setArtists() expects string and raises a TypeError when given a list or tuple

    InfoTagVideo.setArtists() expects string and raises a TypeError when given a list or tuple

    Bug report

    Describe the bug

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

    The setArtists() method of InfoTagVideo expects a string despite being documented as expecting a list. https://alwinesch.github.io/group__python___info_tag_video.html#gad35ce83f3d549079099e31d812735c31

    It raises a TypeError when given a list

    TypeError: argument "entry1" for method "setArtists" must be unicode or str
    

    Expected Behavior

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

    The method should expect a tuple or list as per the documentation.

    Possible the documentation is incorrect but my initial assumption is that it would be expected to function the same as other similar methods such as setStudios or setDirectors. Additionally, the original setInfo() method accepted a list.

    Actual Behavior

    The method expects a string and raises a TypeError when given a list as per the documentation

    Possible Fix

    To Reproduce

    Steps to reproduce the behavior:

    info_tag.setArtists(['Artist1', 'Artist2'])

    Debuglog

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

    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

    • [ ] macOS

    • [x] Windows

    • [ ] Windows UWP

    • Operating system version/name: Win 11

    • Kodi version: Nexus

    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 jurialmunkey 1
Releases(19.5-Matrix)
Meme Maker open source iOS app made in Swift.

Meme Maker Add customized text to popular images, or choose your own, share with the world. Screens Features Select or search a meme from a huge colle

Meme Maker 60 Dec 17, 2022
Full source code for the ComicFlow comic reader for iPad

Overview Finally a comic reader for iPad done right! ComicFlow was designed with one goal in mind: providing the best experience for comic fans with l

Pierre-Olivier Latour 358 Dec 18, 2022
Steganography on iOS and macOS

Pictograph Pictograph is the best steganography app available for iOS and macOS. Easily send hidden messages to anyone you want. You can even encrypt

Adam Boyd 60 Nov 24, 2022
:eyes: Face detection and recognition iOS app with OpenCV

Facemotion Facemotion it's an iOS app, allowing you to find easily a contact by face recognition. Scan the face of a person, whether the contact is in

Remi ROBERT 170 Nov 15, 2022
wallabag app for iOS (for wallabag v2)

wallabag 2 official iOS wallabag is a self-hosted read-it-later app. Unlike other services, wallabag is free and open source. wallabag 2 official iOS

wallabag 139 Dec 29, 2022
iOS App that creates memes from images

MemeMaker - iOS App that creates memes from images Screenshots Meme Collection Empty Screen Collection Table Meme Editor Empty Editing Frameworks Used

Jerome Pullen Jr. 0 Oct 26, 2021
Joplin - an open source note taking and to-do application with synchronization capabilities for Windows, macOS, Linux, Android and iOS. Forum: https://discourse.joplinapp.org/

Joplin® is a free, open source note taking and to-do application, which can handle a large number of notes organised into notebooks. The notes are sea

Laurent 33.7k Dec 30, 2022
OONI Probe is free and open source software designed to measure internet censorship and other forms of network interference.

OONI Probe iOS OONI Probe is free and open source software designed to measure internet censorship and other forms of network interference. Click here

Open Observatory of Network Interference (OONI) 59 Nov 2, 2022
A PSP emulator for Android, Windows, Mac and Linux, written in C++.

PPSSPP - a fast and portable PSP emulator Created by Henrik Rydgård Additional code by many contributors, see the Credits screen Originally released u

Henrik Rydgård 8.2k Jan 9, 2023
Open source iOS app to track COVID-19 cases in a beautiful, easy-to-use interface

Covidcheck Covidcheck is an app that allows people to track COVID-19 cases in an easy-to-use interface to increase awareness and preparation. Unfortun

Julian Schiavo 255 Aug 11, 2022
Switshot is a game media manager helps you transfer your game media from Nintendo Switch to your phone, and manage your media just few taps.

Switshot is a game media manager helps you transfer your game media from Nintendo Switch to your phone, and manage your media just few taps.

Astrian Zheng 55 Jun 28, 2022
A card viewer demo for Idolmaster Millionlive Theater Days written in Swift UI

Misaki Gallery A Millionlive's cards gallery to demostrate Swift UI. All api and

Spike 0 Dec 20, 2021
Android/iOS Apps created to practice with different iOS/Android Tech. These apps were built to have similar feature sets using native Android/iOS.

AgilityFitTodayApp Android/iOS Apps created to practice with different iOS/Android Tech. These apps were built to have similar feature sets using nati

Lauren Yew 1 Feb 25, 2022
XMachOViewer is a Mach-O viewer for Windows, Linux and MacOS

MachO file viewer/editor for Windows, Linux and macOS. Heuristic scan String viewer Hex viewer Disasm viewer(x86/64,ARM,PPC,m68k) Entropy viewer Hash

Hors 505 Dec 20, 2022
3D Shoot'em Up written with OpenGL ES 1.1/2.0 running on iOS, Android, Windows and MacOS X.

SHMUP This is the source code of "SHMUP" a 3D Shoot 'em up that I wrote in 2009. It is very inspired of Treasure Ikaruga, the engine runs on iOS, Andr

Fabien 242 Dec 16, 2022
An efficient, small mobile key-value storage framework developed by WeChat. Works on Android, iOS, macOS, Windows, and POSIX.

中文版本请参看这里 MMKV is an efficient, small, easy-to-use mobile key-value storage framework used in the WeChat application. It's currently available on Andr

Tencent 15.4k Jan 6, 2023
The Outline Client is a cross-platform VPN or proxy client for Windows, macOS, iOS, Android, and ChromeOS

Outline Client The Outline Client is a cross-platform VPN or proxy client for Windows, macOS, iOS, Android, and ChromeOS. The Outline Client is design

Jigsaw 7.3k Dec 31, 2022
This is the take home project from Lululemon for the role of Sr. iOS Software Engineer

Lululemon-Assessment The project has been completed. Please check below sections for more details :) Challenge Build two screens as shown above. The f

Amogh Joshi 3 Oct 24, 2022
Home-assistant-swift-sdk - Used to integrate the Home Assistant APIs with your Swift-based apps.

home-assistant-swift-sdk This open-source library allows you to interact with a Home Assistant instance in your Swift-based (e.g., iOS, macOS, etc.) a

Alexander Golden 0 Dec 31, 2021