Best Live TV Addons for Kodi 2017 – Watch Live TV on Kodi

Whether you’re out of town, stuck on the late shift in the office, or simply don’t have a TV that allows you catch your favorite shows, getting access to live TV on Kodi is simple and easy. There are dozens of different live streaming add-ons on Kodi. Here are the best live TV add-ons for Kodi, with […]

The post Best Live TV Addons for Kodi 2017 – Watch Live TV on Kodi appeared first on News, Tips, and Tutorials for the Cord-Cutting Revolution.


Quasar Kodi Addon – How To Install Quasar on Kodi

Quasar is one of the most popular torrenting addons for Kodi on the web.  Like most torrent powered Kodi addons, Quasar allows you to start watching a video torrent file before it’s finished downloading.  It also scrapes multiple torrent sites, allowing you to search the internet’s most popular torrents sites simultaneously. Want to learn how to install Quasar on […]

The post Quasar Kodi Addon – How To Install Quasar on Kodi appeared first on .


Best Kodi Addons for August 2017 – 4 Hot August Addons

Hello and welcome to another edition of our monthly addon roundup!  In this article, we’ll be showing you how to install 2 Kodi addons that have experienced a big popularity surge in recent weeks: Streamhub and Covenant.  We’ll also be introducing you to an Exodus clone called Gurzil and a totally brand new addon with […]

The post Best Kodi Addons for August 2017 – 4 Hot August Addons appeared first on .

GSOC 2017 Update – Python3 Update

Next we have Arpit’s work upgrading Kodi’s add-on backend from Python2 to Python3

Python3 Support – arpitn30

My initial proposal was to support both Python2 and Python3 in Kodi by maintaining two versions of the same libraries and calling the required one depending upon the meta information in the XML files of the add-ons.


During the first week of June, I was mostly understanding how everything was being built and what needs to be changed. I initially thought of updating the input to swig so that it can output python3, but I realised that Swig only changed the code to generic ML code which was given as an input to Groovy which with the help of Python Templates outputs Python code. So I cloned the Python templates directory and in the later weeks, I started to study and gradually change the python templates to that of Python3.

Aside from the major unicode string change, Python 3 changed a lot of things at the base level that drastically affected the Python-C API which was used to build the templates. So I went through each and every function and decided if it should return a unicode object or a byte object. I changed all the Python API function names, the module initialization, the Py_TPFLAGS, and changed the char data type in C to wchar data type. I also looked at all the data type which were being converted from C to Python and Python to C and inspected if any changes to data types in Python 3 like ‘map’ returning and iterable instead of lists and also changed the PyInt type which was no longer being used in Python3 API.

During the mid of June, when I started working to support both versions of Python, I was told to test if my code supported was even working with Python3 or not. So I forked my current working branch into 2 branches, one to test if my Python3 templates work correctly (testpy3) and the other to support both Python 2 and 3 (build2n3) and was working on them simultaneously. I also updated the HttpNetworkHandlers to Python3.

In Build2n3 branch, I changed paths of the Python libraries to the new Python3 directory, updated the Cmake files to download dependencies for both and keep them seperate.

In testpy3 branch, my main focus was to run the environment with as minimal changes as possible. So I removed 2 python template directories and made python3 the main directory. I had to change all the cmake files though to the updated dependency structure. After all the kinks had been removed Kodi was able to run with Python3 at the end of Phase 1 but the add-ons weren’t working yet.


The first thing I needed to do after the end of Phase 1 was to get the Python3 version of Kodi working, so that I could know if my code was working or not. The major trouble was that there wasn’t any way to know the error except the for only Log Entry of PythonModules not found. I skimmed through each and every documentation to figure out the changes which were made and the difference between them.

I found that the threads and GIL in Python3 are implemented differently than Python2. The acquirelock and releaselock functions are now deprecated and had to be changed with acquirethread which needed to have a saved state beforehand.

But the problem about the threads was still not solved. After a lot of testing and help from Paxxi and Rechi, we were able to identify the problem which was due to the duplication of state of _PyThreadState_current by Kodi and Python Bindings which resulted in the thread state being lost mid execution and we solved the problem by changing the cmake file in templates and adding the python binding directly to the xbmc core library.

After that, I started working on Build2n3 branch to apply the changes which were done in testpy3 branch and to figure out if it was possible to create two versions of libraries with the different implementation of threads even though it meant building Kodi twice while I was still looking into the ModuleNotFound error in the other branch which was still not resolved.

So I started working on Build2n3 branch. The problem I was having was with the env variables like PythonLibs and Python_include_dirs which can be only set to one of the versions at a time so we had to unset the variables after they were used and set them to the python3 directory. 

The main point now was if it was practical to go for a version that supports both Python 2 and 3 or skip a version and release just a python3 version whle giving the developers time to port. Changing a major amount of code just to support Python 2 and 3 only to revert it back to the current code one or two versions later seemed impractical if not impossible due to changing the implementation of handling of threads. Taking in account the time it took, just to find the bug and get just the Python3 version right, Razze asked me to focus on just Python3 version for now.

So going back to testpy3 branch, after searching for several days, we found out that the function which initialized the modules did not add it to the built-in modules in Python3 which wasn’t mentioned in most of the Python3 Porting guides. So we added statements to explicitly add it to built-in modules. And finally the ModuleNotFound error was gone.

After fixing a few bugs like correcting the charset conversion to wchar, updating the execution script, Python 3 Kodi was finally working with the built-on Kodi libraries being perfectly imported. 

In the next week, I checked the best way to make Kodi add-ons compatible with both versions of Python either by using __future__ packages or by using sys.major_version condition and I decided to go with the latter. I also made the versioncheck addon compatible with Python3 and added a pr to it. The addon was working perfectly with current version of Kodi as well as the Python3 version of Kodi.

Lastly, I decided to update the Python3 branch with the changes which were later made in the templates while working to support just Python3. So if we decide to go for a version to support both Python2 and 3, we can just fork from there. 

I also added the PyFile function into Kodi itself thus removing the dependency on Py3c fileshim.h.

I also tested the debug and release versions of Python3 Kodi on Windows 64 bit and it worked without any problems.

The Future

I’ve tested my code with Ubuntu using the natively installed packages and it seems to work. And after a few days, I’ve been able to build the master branch in Linux using the target packages only. I intend to finish updating the files for target version for Posix systems by the end of next week. I will port some of the add-ons to Python3 later on, and I need some time to clean up the code as well. Although I removed the commented code which I left behind from Python2, I still have to give it a final review before submitting my code. 

GSOC 2017 Update – Shader Support

Now that we’re 2/3rds finished with GSOC 2017, I’ve invited our intrepid student developers to spend some time writing about how their projects are going so far. For those of you out of the loop, the three projects this year are implementing shader support in Retroplayer, upgrading Kodi to Python3 for add-ons, and getting Kodi to natively support Wayland in Linuxland.  

We’ll start with Nick’s update on Shader Support, and release the other updates throughout the week.

Shader Support – Vel0cityX

My initial proposal was about implementing shader support in RetroPlayer as well as a variety of default shaders to go with it.

However, quite early on, it was suggested to me that I try something more ambitious and implement the same spec that libretro shaders use. This spec essentially introduces shader “preset” files; configuration files which allow for multi-pass shader configurations to achieve advanced filtering, without manually copying and pasting shader code all over the place. They have other features too, but this is their core funtionality and reason of existance. The biggest advantage of implementing this would be that the are already many many shaders that support this format, both for OpenGL (ES), and Direct3D.

So, I changed my proposal accordingly and began research.

To give a bit of background, it is important to mention that RetroPlayer doesn’t have its own renderer; it never did. All of its rendering is entirely reliant on VideoPlayer (the backend and renderer used when playing any kind of video). Thus, it was clear since the beginning that I would need to get around this problem one way or the other.


The first month I was really busy with university exams, so unfortunately my time spent on this was less than I’d like.

I had never worked on Kodi before, so initially my time was spent creating a development environment ready (I faced lots of problems on that front), as well as getting acquainted with some of the relevant parts of the codebase.

At the start of June, I booted up RetroPlayer for the first time and instantly noticed something that I didn’t quite like: the scaling. Apparently the Windows renderer didn’t support nearest neighbor scaling, so, the first (productive) thing I did was implement nearest neighbor video scaling for Windows. Maybe not directrly related to my proposal, but it made me familiar with a part of the code base I would really need to know the ins and outs of, for the weeks to come.

Towards the middle of June and start of July, I started working on a new renderer for RetroPlayer, based on VideoPlayer.


After that, I needed to get shader presets to load and after a bit of discussion with Garrett, I decided to go with a binary add-on, which would use RetroArch’s implementation of .cgp parsing.

The start and middle of July was spent on diving in the crazy world of binary add-on development, making a new binary add-on type, building a basic API for it and getting it to work from inside Kodi. There’s still work to be done on that front, but all the framework is setup now and it works.

There are about 6 layers of abstraction between the add-on and what Kodi sees (!), so unfortunately changing the API is quite tedious (depending on how many layers change).

It was needed though as RetroArch’s parsing code wasn’t compatible with Kodi’s licence.

After getting this to work, Fernet’s changes to VideoPlayer upstream caused my renderer to be quite useless and in need of a rewrite.

I wasn’t gonna spend more time on this, since my proposal was already enough work as it is, so I decided to go with a different approach instead.

Without getting too technical, with the new approach RetroPlayer is still dependent on VideoPlayer, but less so.

Still, this won’t be mergeable upstream, since people will want RetroPlayer to finally get its own renderer.

Doing it in a better way (but still quite messy) would require me to remake the renderer by copying VP again, so I’d rather focus on getting a minimum viable product first before diving in to that.

If there is time, I will work towards that, but getting an MVP is my top priority at the moment.

The Future

I have started working on the core part of my proposal since the past week or so.

By “core” part, I mean getting shaders to actually renderer.

This of course involved diving deep into graphics, Direct3D 11 in particular.

The latest issue I faced had to do with the fact that all libretro shaders that I thought would compile happily with Direct3D, didn’t.

Without getting too much into the details, these shaders were written in a slightly different shader language (Cg) than the one D3D uses (HLSL).

I could probably wrap up the backend and implement a bunch of pre-set shaders myself for users to use and call it a day, but I didn’t want the whole shader preset thing to die, especially given its benefits and the effort I’ve already put into it.

So, I emailed libretro’s main developer and we discussed for a while, he then invited me to their IRC channel and we came to the following conclusions:

  1. Both projects would greatly benefit by porting these shaders to Direct3D. Cg is very much legacy software at this point and they would like to get rid of their Cg shader code.
  2. There are around 600 shaders that need porting, which are used in different combination by around 500 shader presets. That’s a lot of work for me to do in a month, in addition to the actual rendering backend for D3D and OGL. So, they agreed to aid in with the porting of the shaders. This could only increase libretro’s popularity after all, so both projects benefit.

On the backend side, I’m making quick progress, but it’s quite a lot of work, so I’m not sure how much of the spec I’ll be able to implement in time, especially since, like I mentioned, D3D11 and OpenGL (ES) require different implementations.

Thankfully many shaders don’t use very advanced features of the spec, so they will be compatible. Of course, I will try to implement as much of it I can if not all of it, to make use of as many pre-existing shaders as possible.

If I didn’t face so many unexpected issues (and I hadn’t lost almost a month due to exams) things might’ve been different, but what can you do; these things happen.

All in all, I’m hopeful for August. No doubt it will get quite intense since it’s the final stretch, but I’m ready for it!



Best Kodi Bollywood Addons for Desi, Hindi and Punjabi Films – Top 8

Although American and British films are universally popular, Bollywood is still big in and outside of India. Many Kodi Bollywood addons are designed just for Bollywood fans, streaming great content direct from India. And while some of the best Bollywood addons for Kodi are Bollywood-specific, there are many well-known addons that cover the gamut from […]

The post Best Kodi Bollywood Addons for Desi, Hindi and Punjabi Films – Top 8 appeared first on .

Having issues with free Movies, TV Shows, Sports, IPTV Streams?

Due to recent legal action against websites and repositories promoting add-ons that use pirated (stolen) media content, many have shut-down their services. This is driving a large increase in users complaining in our forums and on social media about their “Kodi Box” no longer working.

Team Kodi (the unpaid volunteers who create Kodi and manage the Kodi name/brand for love not money) have never manufactured a “Kodi Box” and we do not supply media content. People who have been selling “Fully Loaded” devices on Amazon, eBay, Facebook, etc. or provide “IPTV Streaming” services with impossibly $cheap subscriptions to improbably $large selections of Movies, TV shows, Live Sports, etc. are not affiliated with the Kodi project. They are criminals who profit from piracy.

Criminals selling “Pirate Boxes” are supported by an ecosystem of “Kodi News, Help and Tips” websites promoting “the best Kodi add-ons” and services (for pirated/stolen content) and YouTube clowns who output an endless stream of diarrhoea that redefines #fakenews. These sites and channels do not exist because their operators are die-hard Kodi fans who want to help the community. They exist because the operators are die-hard fans of the advertising revenues being generated. Local courts must decide whether they are also criminals, but it is obvious they sustain and profit from piracy.

If you post in our forums or social channels about a pirate add-on or streaming service not working please expect ZERO sympathy or support. We don’t care. We care less than not caring. We don’t care biggly. And to counter a popular comment; if the Kodi userbase drops a huge percentage because pirate services flee or die, we’re fine with that. Kodi has been around since 2002 and we are not going to implode or disappear (unlike the pirates). Life will be a little quieter, but less time spent on self-entitled whiny people means more time writing great code and having fun. We’re okay with that too.


If you’ve had enough of dubious repo operators and want to free your legal add-ons from the taint of piracy, please come talk to us. Team Kodi wants to help you publish in the official Kodi repo where add-ons are seen by all Kodi users. In the past we’ve been a little slow to approve changes, and sometimes we’ve been critical about coding. There are still some ground rules on submissions but we now aim to publish updates in under 24 hours and the purpose of code review is to coach not chastise. In recent months we cleaned up our submission process and invited popular add-on authors to join Team Kodi or Slack to improve communication and collaboration. If you have legal add-ons that need a permanent home, let’s chat.

Kodi v18: Windows 64-bit is here

After years of work we can finally announce that Kodi v18 will be available as full 64-bit Windows application. This means we run 64-bit on all capable platforms which is quite the achievement.

What took you so long?

You have to understand that Kodi is a very complicated piece of software and there wasn’t a simple switch to say give me 64-bit. Since 2012 users have been asking for a 64-bit version as it was supposed to be a lot better. Over the years there has been no obvious proof that switching to 64-bit actually had any benefits for the Kodi application. In the meantime other platforms like Linux, OSX and even Android did move onward and received a 64-bit version. Only the past year or two we have slowly been seeing benefits with all the new video formats coming out and the increased development support for FFmpeg which is at the core of our audio and video playback. So then what hold you guys back so long is what you might ask? This answer is actually quite complicated and has to do with things like how we compile the code and the external code libraries available. 

The work needed

Since we originated on the XBOX we had a lot of legacy code related to Windows which wasn’t there for other platforms. Code was scattered everywhere and tied together in the most impossible ways. Slowly we started to clean up our build system and the core code that would make it possible to have a 64-bit version. Over time other platforms did add 64-bit support as the way we build them is totally different. Their main advantage point was how the external libraries that were used were built as it was almost as easy as just set compile to 64-bit. On Windows however we had to rely on the external library teams to provide such 64-bit versions and sadly almost none were available.

During past years several of our team tried to improve this situation and started to work getting those libraries updated to be 64-bit compilable and compilable. This is a huge undertaking as some were simple never intended to be anything else than 32-bit. Slowly but steadily the work progressed and after currently having ported 31 !!! external libraries to 64-bit we are finally in a state that Kodi is usable and near feature complete. There are still some missing packages and add-ons but we hope that those get done quite soon to have it on par with Kodi as you already know.

To start using this Windows 64-bit version is nothing more than downloading the 64-bit installer and install it on top of your current Kodi version.

We would like to thank karlson2k who started this work and Paxxi and Rechi who finished the job and got Windows 64-bit a reality. Of course let’s not forget everyone else who helped getting this a reality or contributed to development.

What about UWP

You might wonder where the UWP version is that a lot of you are longing for so they can run it on their XBOX One? All we can say is that it is being worked on and work is slowly progressing. Getting Kodi running as 64-bit is actually a big step towards UWP because it involved the same external libraries issue that needed to be solved and compiled. However on top of that we have to change or remove over 800 function calls that are not permitted or unavailable and those need to be solved for having a functional application. So for now there’s no UWP yet. Should this change we will be the first to let you know.

Where can I download Kodi?

As alway you can find the official builds on our download page. Then click on the platform of choice and choose development build. You can install these builds just on top of your current Kodi installation without doing a reinstall or cleanup as we do a full migration if needed. Be carefull though because it is still early in development and some unwanted side affects might come up. Some examples are incompatible skins or certain add-ons will not work properly.

Bug reports

Please report any problems on our forum in the appropriate support section. Don’t forget we also have some official tablet/phone remote controls for both Android and iOS. You can find the links to them on the download page.

Apparel, donations or getting involved

With Kodi 18 having a galaxy far away theme to it, we decided to take inspiration from the baddest of baddies with this shirt. Vader pioneered black on black. We figured we’d follow his lead.  You of course also order other shirt in our shop.

Getting involved is quite easy. We encourage you to report problems with these builds on our forum first and after that, if asked, submit bugs on Trac (following this guide: How to submit a bug report). Do note that we need detailed information so we can investigate the issue. We also appreciate providing support in our Forums where you can. You can of course also follow or help promote Kodi on all available social networks. Read more on the get involved page. We are always happy to receive a donation by which you show your support and appreciation, and t-shirts and Raspberry Pi cases may still be found on the sidebar for purchase. All donations and other income goes towards the XBMC foundation and are typically used for travel to attend conferences, any necessary paperwork and legal fees, purchasing necessary hardware and licenses for developers and hopefully the yearly XBMC Foundation Developers Conference.

Seven years ago we said goodbye to the original XBOX

Seven years ago on this day we said goodbye to where Kodi(XBMC) once started. On 26 May 2010 we officially announced that XBOX support and it’s development would continue elsewhere.

Here’s the original announcement from 26 May 2010

XBMC (XBMP really) started as a program for modified XBOX consoles. In the following years, XBMC has grown into a multi-platform, multi-architecture media center that runs on most standard hardware. The hardware and legal limitations of the XBOX were always a concern and the Team has instead focused on running on the hardware that most people already have.

The last official release for the XBOX by the XBMC team was Atlantis, over 18 months ago. Since then, one brave soul (Arnova) has been merging code from the main codebase into the XBOX branch in our repository. Because there were many users out there that took advantage of these updates, we had no problem with this.

But times have changed. The XBOX has hard limits for what it can handle. Some users are satisfied with these limits, and we encourage them to use XBMC there if they are happy. But it is a popular misconception that official XBOX development is still taking place by the team, so we have decided to set it free. We have enough on our plates already, and worrying about a deprecated platform just increases our workload. A few days ago the XBOX branch was finally removed from our subversion repository.

But loyal XBMC for XBOX users fear not! In addition to his role as an XBMC developer, Arnova plans to continue development on the XBOX — just not here. You can find the new project’s home at sourceforge. We’re leaving it in his hands to decide how to handle the project’s administration. How he manages the forum, bug tracker, scm, developers, etc. is up to him. In other words, don’t complain to us ;-)

In order to help users to find relevant help and discussion, we will be making the XBOX section of our forum read-only on Monday, June 07. It may be moved in the future, but for now it will stay for reference. This also means the end of XBOX support in the wiki and IRC.  Arnova has requested a snapshot of the wiki that he may host if he wishes as we begin to prune XBOX-specfic information from ours.

We wish Arnova and the project the best of luck as we bid a fond farewell to a big part of our past.

Now seven years later the project still lives on at and on 27 February last year they released their 3.5.3 version for the original XBOX. It’s amazing that the old XBOX is still alive and used as media center device with a lively community around it.