Articles by Prof Yaffle

Kodi 18.0

Kodi 18 is here!

<drum roll> … after another long gestation… the Kodi team is very pleased to announce the immediate availability of Kodi 18.0 “Leia” for all supported platforms (UWP for Windows Store and Xbox is working its way through the system as I type, so will be available shortly…). While we were planning to move more to a “release early, release often” model, this has some significant changes that really needed to be tested and bedded in before we launched it, so it did take a little longer than we’d hoped. It was, though, a worthwhile wait 🙂

To put it in some kind of context, this version includes:

  • Approaching 10,000 commits (code chunks changed)
  • More than 3000 pull-requests (collection of commits that were included in one go)
  • Nearly 9,000 changed files
  • Nearly half a million line of code added, and much the same number removed
  • Over 36 open source developers
  • A lot of dedicated free time conceiving, designing, developing and testing these changes (and all the infrastructure you see around them, including this web site)
  • Quite literally many, many cases of beer and wine

We’ve covered many of the detailed changes in this release in previous blog posts, but here’s a quick summary of what you’ll find in this new release:

Retroplayer gaming and associated game control support

One of the big features of this release: support for gaming emulators, ROMs and controls. This is a significant topic in its own right, so look out for future posts on this, but suffice it to say at this time that you now have a whole world of retro gaming at your fingertips, all from the same interface as your movies, music and TV shows. For the genuine experience as well, we’ve also introduced support for joysticks, gamepads, and other platform-specific controls, so the games will work just as was intended.

Digital Rights Management decryption support

Early days in many ways, but this opens a whole new world of content for Kodi. Depending on your hardware and licensing, Kodi can now access external DRM handlers and then play subscription content just like any other local media. This is significant in a time when so many people are switching to protected streaming content; there are already several add-ons available that make use of this functionality, and we genuinely hope that we’ll see support from other content providers in the future.

Music Library – new ways to explore and enjoy your music collection

Significant improvements including better filtering (media source, artist gender, type etc.); artist sort name; enhanced artwork; faster API access (particularly useful if you’re controlling Kodi by remote with the TV off). Creating and using the music library is even smoother than before. If you have never bothered to use the music library, or maybe never even used Kodi as a music player, then we encourage you to try this feature in Leia!

Live TV improvements, including support for new back-ends

Support for RDS (Radio Data System), automatic selection on startup (“boot to live TV/radio”, if you like), improved OSD and PVR information, enhanced EPG and PVR actions, and many more. Back end support has been updated across the board, with new support for Zattoo, Teleboy, and Sledovanitv.cz .

Binary addon support and the binary addon repository

While we’ve actually been using platform-specific binary addons for some time – think PVR addons and screensavers – there’s been a lot of work to expand this functionality and move to a more modular architecture as a result. This has effectively halved the main Kodi installer in size, as you now have the option to install some of these functions as you need them instead of them coming pre-bundled. The architecture also now opens the door for other types of pre-compiled binaries, perhaps to provide access to different media sources. The binary repository is currently available for Android, OSX and Windows; Linux users will still have to use the PPA, while iOS and UWP will continue to include the binary add-ons in the installer because of platform limitations.

Android Leanback and voice control

Kodi can now show its library contents on the main Android TV interface, with full voice functionality: unwatched random movies and unlistened-to albums, binge watch suggestions, and more. Voice integration allows you to search for content with Google Assistant, using the same feature for “voice typing” wherever you see the traditional Kodi on-screen keyboard.

Playback improvements (audio and video), including improved Blu-ray support

The video player is core to so much of what Kodi does, and some significant changes have been made to the architecture to ensure we’re better able to cope with 4K, 8K, HDR and similar, as well as keeping up with the variety of CODECs out there. Changes have been made to priority, to ensure that video gets the most attention from the CPU/GPU for smoothest-possible playback. Elements have been moved out into binary addons, so components can potentially be updated outside of the main Kodi code base.

We’ve also improved Blu-ray support in terms of disc detection and metadata, BD-J menu support (subject to Java support on the device), there are updated external interfaces for e.g. MPEG DASH and RTMP input, and there are improvements to 3d playback (including in 2D mode) and various changes to specific CODECs.

On the audio side, there’s a wealth of improvements and new support for all types of playback system: ALSA, PulseAudio, OSS, Pi Audio, DirectSound, WASAPI, Darwin, SndIO

“Estuary” skin modifications and changes to the GUI/skinning engine

Many of the other changes listed here have an obvious ripple effect on the Kodi interface, so we’ve made change to support these: the gaming modules and associated libraries and the PVR changes, for example. We’ve also updated keyboard layouts for more languages, updated image resources, changed API calls, improved response times with optimisations for e.g. scaling and redrawing.

Revised codebase and build guides

Starting with this release, our build guides are kept up-to-date against the current code base – current, as in (hopefully!) up-to-date against a single pull request or code commit. That means that we no longer need to maintain How-Tos and standalone guides, and you will be able to reliably find a build guide for any point in time, even retrospectively.

Platform Specifics

As a multi-platform application, Kodi inevitably has to be updated in different ways for different operating systems, whether that’s simply to keep up or whether it’s to unlock new functionality. Android gets API bumps, speech-to-text, SD card support, among other things; BSD gets all-round improved support, especially on the video (VAAPI/VDPAU) side; Linux gets DRM, Mir/Wayland support, numerous video improvements, and build system changes; iOS gets support for iOS 10, improved VDADecoder support, and general improvements on both TVOS and arm64 IOS; and Windows finally gets 64-bit binaries, along with improved UWP compilation, enhancements to image rendering, and another slew of general platform-specific improvements to how we handle libraries and APIs. 

… And Other Things

Of course, there have also been a huge number of other changes, some of which will be invisible to very many users. Bluetooth support, CMake build system, visualisations and screensavers, improvements to the JSON-RPC API, improved code stability, performance. and security (as well as general code clean-up in many core areas), remote control changes, web interface changes, logging changes, dependency changes… the list goes on. Do take a look at the change log and detailed commit history (below) if you’re really interested in looking behind the curtain! 

 

The V18 “Leia” T-shirt

Inspired by the “galaxy far, far away” theme, our resident artist Sam went above and beyond and designed perhaps the coolest Kodi announcement video of all time.

We loved his work so much that we’re modelling the Kodi 18 shirt after it, along with more art to come. Here it is, our newest, coolest shirt: K-18L – available in several shirt colours and not just black or white.

Kodistore

 

Changelog

The Kodi 18 changelog wiki page gives a list of changes for this release; those seeking a more technical listing can view the merged pull requests on GitHub.

 

Thanks

As always, this is a huge team effort, and our collective thanks go out to all the developers who submitted code, whether that was thousands of lines of a core new feature or a couple of lines to fix a skin bug. Thanks go out to the ecosystem of add-on and skin developers who updated or created new add-ons to use new functionality in Kodi 18.0. Likewise, we’re indebted to the many beta and release candidate testers who took time to explore the pre-release application, file bug reports, test fixes and assist the team with resolving issues. And finally … special thanks go our to our tireless team of forum moderators, and all those who spend time in our forum and enjoy being part of our community to share tips and tricks and help others. Without all of you, this project would be nothing.

 

Help!

If you experience any issues or find any remaining bugs, please post in the General Support section of our forum (please be mindful of our forum rules when posting!). If you have fixes for issues please submit a pull request with your changes to our master branch on GitHub. We also welcome users who want to help answer questions in the forum or write articles for the wiki.

 

Donate

To show support and appreciation for Kodi, please consider making a donation or purchasing merchandise such as a T-shirt or Raspberry Pi case. All donations or profits go to the XBMC Foundation and are typically used for team travel to attend conferences, operating expenses, hardware and software licences for developers, legal fees, and the annual developer conference.

FOSDEM 2019: Brussels, 2/3 February

Belgium, here we come! Team Kodi will be at FOSDEM in Brussels next week. If you live anywhere near, if you’re attending, if you can make the detour – please, come along and meet some of the team.

FOSDEM is an annual, volunteer, non-commercial event that focuses on free and open source software development. It’s primarily aimed at developers, although the talks and stands are open to anyone who’s interested. Its main aim is to simply create a meeting place; it’s a fantastic opportunity for people to mix, chat, share ideas, collaborate, promote awareness, and generally interact with like-minded individuals. 

So, every year, thousands of developers from all over the world descend on the Université Libre de Bruxelles to do just that. This year, there’ll be representatives of projects such as Gnome, Mozilla, Debian, Python, GitLab, LibreOffice, Apache, VideoLAN (and many, many more) – and some of the Kodi team as well. We won’t have a stand but, in between attending and delivering talks and generally mingling, we’d love to meet with our friends in the community who might be reading this.

 

Kodi v18 “Leia” Presentation

Martijn from the team will be presenting the final release of Kodi 18, the next release in everyone’s favourite media centre software. He will be taking people through the latest features to be introduced, as well as some of the changes that have been made “behind the scenes”, and what these mean for developers and users. He’ll also set the scene for what you can expect as we now build on these foundations and move in anger towards v19 development.

Room H.1309, Saturday 2nd February, 11:00-11:25.

 

Kodi Team Meetup

It doesn’t matter whether you’re a user or developer, whether you work with Kodi or something else, if you have commercial interests, or if you’re simply curious. Pop along if you’re interested; several Team Kodi members will be present to chat at your leisure.

Room H.3242, Saturday 2nd February, 16:00-17:00.

 

More information on the presentation here, meeting here, and on FOSDEM itself here.

We hope to see you soon!

2018 – Looking Back…

So, the sun starts to set on 2018, and another year draws to a close. At the same time, we stand ready to launch Kodi 18 “Leia” in the very near future, which opens a new chapter in how Kodi is structured, how it functions, how it’s used. It seems like an appropriate time to stop and draw breath, then, and take a look backwards: what’s been good, what’s been bad, the what-went-wells, the where-do-we-still-have-challenges.

First up, then, the positive stuff

Internally, there have been very many changes and improvements to Kodi’s core code that, while not immediately obvious on the outside, make life a lot easier to both maintain and expand the application. Architectural changes, such as the move towards Python 3; support for Python scrapers and binary addons; movement of functionality out of a global/core approach and into a more local/modular system; improvements to the Videoplayer such as shader support and overall speed/quality improvements. And it’s not all about the code itself: documentation has been revamped, with some superb work and good ideas on how we can better keep track of how Kodi is built.

The Kodi Team continues to grow, with new members joining us in every capacity. That allows us to be more structured with our internal processes, as well as (e.g.) bringing in more Google “Summer of Code” students to work on specific elements of the code. Indeed, a shout goes out to those GSoC students this year: good work, done professionally, seen through to the end, rolled into the application. As some of them joined us this year at DevCon, we’ve put effort into making that meeting more structured, constructive, focused, and more accessible to the new Team members so they feel more welcome, more quickly. We have an active team of round-the-clock moderators who work to keep our forum in shape – violations, spam, noise. Add a sprinkle of automation here and there and, hopefully, users can find what they need and get the community help they want without getting buried.

One of the eternal challenges in any large, dispersed organisation – perhaps made more so when everyone is a volunteer – is internal team communication. We’ve made active steps this year to improve this: new internal tools, more collaboration, more organisation, greater transparency and openness. We all know how the open source community can have some famous and pretty public disagreements; while we still have our fair share of these within the team, we’ve generally put a lid on the worst of these, diverting energy into the application instead of internal arguments. This also extends to external communication and interaction sometimes: having spent some time on self-reflection, we’re a lot more aware of how we come across to new developers and contributors, and how attitude can impact directly on people’s willingness and ability to contribute. We’re continuing to work on how we use GitHub and the pull request process, for example, to hopefully get more contributions, more quickly – submitted, reviewed and committed.

Extending the idea of external communication, we’ve made some major updates to the wiki, many of which reflect the significant functionality changes we’ve seen. We have the new forum, and new paste site, and generally a much more usable and polished public face. Linked to the submission/merge process as well, we’ve actively sought to get more external testing of changes through mirrors and nightly/test builds, all of which combines to give more stable code and a better user expereince all round.

Now, for a lot of users, much of that might be all well and good – “what about the application features, though?”, I hear you cry. Fear not, kind reader, for there has been much work there as well. From platform support, such as H.265/HEVC on Pi and collaboration with Android SoC vendors, to DRM support and possibilities that opens up for official content add-ons; a return to our roots with Xbox One support; the release of the long-awaited retroplayer gaming support as part of the official Kodi build; a significant re-work of our music and related library capabilities. Some of these are admittedly more revolutionary than others, but all of them build a more solid, stable, expandable platform for future releases.

 

Is everything perfect, though? No, of course not. Any retrospective has to really look at where we still need to improve.

We’ve made great steps forwards on communication: we can still do much more. We need to streamline our internal tools so people get to know about what they need and not drown ourselves in noise (forum, Slack, GitHub, email…). We’ve been working on internal policies to resolve issues between team members – we’re not a company, we don’t have an HR department, so we need to simply agree “the rules of the road” that govern attitude and acceptable behaviour (hey, we’ve all been on the Internet long enough, you know what it’s like sometimes!). That in turn touches on the external communication and attitudes towards people: we still need to complete the pivot from “this sucks…” to “thanks for the contribution, might I suggest…”. Streamlining the code, documenting it better, modularising it, making it easier to offer up changes without spending five years familiarising yourself with all aspects of the code base – all of these will hopefully help on this aspect.

GSoC has been a success for us, as covered above. But we always need more developers and new ideas. We need to become a more attractive project to work on and work with. We need to be more accepting of change, more welcoming of criticism or suggestions, more open and transparent about how, why and where things happen in what is increasingly an enormous, “black box” project from the outside. While all projects of this type are revolving doors of contributors, we lost some core talent this last year; similarly, though, some people have rejoined the Team, resurrecting some of their passion for Kodi and what it could become. The hippy in all of us would like less drama, more love, and for everyone to just get along, all of the time. 

And, finally, we need to work more on the vision for Kodi. It’s true that we’ve been painted with the piracy brush for too long. As we introduce new features, as the DRM functionality beds in, we have to hope that this changes, and we can get back to the primary reason most of us work on this application: because we genuinely believe it is, and will remain, the best one-stop home entertainment and multimedia platform in the world.

 

Those were our thoughts. Maybe you have your own – in the spirit of openness and communication, then, perhaps you can share those ideas with us through all of the normal channels.

In the meantime, as you ponder Life, the Universe, and Everything, we wish you a peaceful end to 2018. Whatever you celebrate at this time of year, whether you celebrate anything at all, we wish you well for now and the future. 

Thank you for sharing the journey with us.

Team Kodi.

 

Devcon 2018 – Sofia – Part III

One more day, with enough content to warrant a separate blog post – partly because people are still here for the most part, partly because of new stuff that’s been added to the agenda as we’ve gone along, and partly because of the topics that, despite our best efforts, managed to escape from previous days.

We began the day with a broad retrospective of the past year: for each person, what went well in the past twelve months, what could have been improved. As you might expect, we covered far too many topics to cover here, spanning as they did nearly every aspect of people, process and technology. However, it was a useful conversation that gave time to both be proud of the positive while reflecting on where we still need to focus more effort. We’ll work through and digest everything that was said and perhaps come back to it as a separate, future post, as the conversation will help shape where we go next.

Next up, lrusak took us through his experiences and presentation at both FOSDEM (Brussels) and Linaro Connect (Vancouver) this year. His talk was mainly aimed at shifting from vendor-specific or closed code (kernel and blob dependencies) to more universal, open source methods, specifically around windowing and rendering on embedded Linux (SoC) platforms such as Allwinner, Broadcom and Qualcomm. As well as simplifying our core code and removing the need for maintenance and use of platform-specific patches, this also has the potential to deliver performance advantages and broader platform coverage. Overall, there are some real benefits once we can tap into specific libraries via standardised kernel calls rather than depend on userspace code that’s in turn reliant on monolithic, all-purpose blobs that may include a whole load of code that simply isn’t needed for Kodi.

We discussed Kodi “remixes” – forks, feature branches, JeOS distributions, and similar variations – and how they link back to our trademark policy and support overheads: what’s allowed, what can we tolerate, what can we manage, how does it appear to our users. This is an area full of opinion and interpretation, rapidly wandering into genuine legal implications. While this is something we really don’t want to have to worry about, it’s something we must keep aware of, as historical experience has demonstrated. As such, we’ll be revisiting aspects of our practices to ensure that we protect Kodi while, at the same time, embracing the broader community where we can see that there’s positive intent and genuine common benefit.

lrusak then returned to the stage to give an update on LibreELEC. That team continues to streamline everything, reducing the maintenance overhead, slimming down the underlying OS overhead, and aligning the user experience more and more closely with core Kodi. He discussed some potential architectural changes that flow out of this goal: future platform support, what libraries could be removed and why (no longer supported or just not needed), what could perhaps be moved upstream so that it becomes part of Kodi and thus not some separate facet of LibreELEC.

And that’s it for day three. Thanks to everyone for their participation, and thanks to the entire community for making Kodi what it is.

One final comment as we close: we really need to offer very many thanks to Roza Zdravkova, who’s been invaluable as our local eyes throughout this DevCon. From helping with transport to pointing out where to go and what to do, she was fundamental to the event’s success. So, “thank you” from the team!

So… that’s it for DevCon 2018. Time to turn to a bit of hacking and development before all going our separate ways once more.

Tags: 

Devcon 2018 – Sofia – Part II

Good morning/afternoon/evening/night (delete as appropriate – we’re a global community). The world has turned once more, the sun has crawled into the sky, and we’re back in the room.

Nate began the day with an update on the Foundation’s financial status: income, expenditure, bank balance, sponsorships and revenue sources. The good news is that we’re financially stable, but the bad is that we’re never going to be rich. Damn this volunteering thing, it’s almost like everyone does this for free. Oh, wait…

Next up, garbear took to the stage to talk about the upcoming (and long-anticipated!) RetroPlayer. This is already available in the 18.x “Leia” builds, so you can try it now if you like. As well as a demo to the team, the presentation covered how we’re addressing controller topology (including hubbing and mapping), user interface options, configuration, potential for user profiles, binary add-on repository structure, and some potential future features.

Martijn next took us through our current user statistics. Because we do no user tracking, it’s always been difficult to get any real numbers, so we’re reliant on partial data: Play Store active user counts, Microsoft app store figures, what we see hitting our repos for e.g. scraper or other add-on downloads. We probably have c. 80 million downloads and c. 30 million recently-active users across all platforms and versions – including some active installations on every release since 13.x “Gotham”. This presentation also led into a conversation about release management, specifically, the intended schedule for the upcoming 18.x “Leia” release plus very early timing plans for 19.x “M*”.

The next presentation was by kib, giving us an update on all things related to the Kodi infrastructure – build servers, download servers, web hosting, caching. He took us through upgrades to the Windows build system, wiki software upgrade, https implementation, the Kodi paste site, LXD containerisation, OS reinstallation and upgrades, changes to mirror up/down detection, CloudFlare, and more.

Finally, a1rwulf rounded out the day by talking about the Kodi databases: the basic architecture, current limitations, and potential changes that we need to consider as new features are introduced.

A shortened day today, with a couple of topics kicked into Sunday for a variety of reasons. Watch this space for an update on those, as we’ll add them in due course, either as an update to this post or as a separate one, depending on content.

Tags: 

Devcon 2018 – Sofia – Part I

<blinks in the light>

What, a year already? Yup, twelve months have passed, we’re all a year older, the world is still mad, and we’re once again sitting in an overly-warm, windowless, anonymous conference room, discussing everyone’s favourite media software while wondering where the coffee is. Welcome to DevCon 2018, coming to you this year from Sofia/Со́фия, the capital city of the beautiful Balkan nation of Bulgaria.

So: Team Kodi Assemble!

We hit the ground running this morning. Mixed in with initial logistics, introductions, and the annual battle with AV and hotel wifi, keith led a conversation about github, and how we could perhaps better use it to track code and project issues. We currently use trac for bugs, which presents more than a few challenges to both casual users and the team; we could also potentially use github for bug reporting/allocation instead, and also use the associated project tracking to also keep better notes of e.g. press conversations, Foundation issues, and similar.

We continued into a conversation about conferences – which are most appropriate, how do we best cover them, what and where, how do we get most benefit. More later on this year’s conference experiences.

Martijn then talked about the move from Python 2 to Python 3: approach, milestones, timeline. Python 2 is EOL in 2020, so this is becoming a more urgent task. The intention is to combine this into the normal Kodi rolling release schedule, so expect a significant focus on Python 3 readiness and enforcement as we move past 18 (Leia) and on to 19 (M). If you’re an addon developer, specifically, then it’s time to pay attention to this as “later” is rapidly becoming “now” – everyone has had ten years to think about this, after all!

The big challenge is how we encourage developers to migrate while not inconveniencing or irritating users. This is a significant change, and some things are likely to break. Blog post here.

We next moved to conduct and standards – not because we believe there are specific problems, but more because it’s generally good practice to have some expectations regarding behaviour of team members and contributors: if you follow the news, you won’t have missed some of the headlines around what can happen when people go beyond constructive disagreement and move into personal attacks, particularly when social media or public discourse is involved. As such, we’re putting in place some clearer ground rules and management policies around our own behaviour, just as we have done around the standards we expect from our forum contributors.

The conversation then moved on to engagement and communication – how we keep people informed, updated, involved. Kodi is a big project, with very many moving parts, and nearly as many ways to interact. That’s not just about the code, but it’s Foundation stuff, user support, strategy, wiki, external conversations, release management: keeping on top of all of these is undoubtedly a challenge. This is very much an internal Team conversation, but one that we’ll continue to progress, as even orientation to the project can potentially be a barrier to new contributors.

Moving on, Martijn led a conversation around issue tracking – trac vs github. While we currently use an internal trac system, and it has some genuine benefits, it’s neither the most usable nor maintanable of systems. By contrast, hosting and managing the issues on (public) github means they’re more closely linked with code and commits, so we’d get some significant advantages there that should more than offset what we’d be missing. If we do make this change, which is likely, it won’t happen overnight, as we’ve much to decide: what to do with old (and maybe no-longer-valid) bug reports, what labelling/tagging structure we’d need, what systems we’d need to have in place to ensure that we receive “complete” reports going forward, and so on. More to come.

Related to this – because github is, in general, a more public platform than trac – we had a conversation about embracing this as a benefit and how we become more open. Again, Kodi is a hugely-complex project and is very daunting to a potential contributor: where to start? Who to talk to? How to get help? Who are all these people, anyway?? So, many thoughts: github conversations, GSoC experiences, public discussion channels, updated build/”getting started” documentation, code documentation/architecture. If you’re a potential developer and feel like you don’t know where to begin, please, contact a member of the team to help us address any concerns you have. We can always use some more help, particularly on the features and multiple platform support that everyone values so much.

Returning to a topic introduced earlier in the day, garbear, Razze and yol took the floor to report back on their attendance at VDD (Video Dev Days) earlier this month (also attended by Martijn and RomanVM). This was also touched on in a previous blog post. Sessions included AV1 CODEC development, including the dav1d decoder and rav1e encoder;  the x265 HEVC encoder; VLC 4.0 plans and features; a series of short “lightning talks” on various AV-related topics; and, of course, many networking opportunities across a common community of interest (website hosting and load balancing, request handling/download management, breakouts on FFMpeg, programming languages…). Useful bridges built with like-minded people, which is ultimately good for the whole open source multimedia landscape.

As the day started to draw to a close, mohit-0212, one of our 2018 GSoC students, gave a presentation on his project around episode intro/outro detection. The goal of this project is to improve the user experience by editing out the endless theme tunes and credits you get, particularly when binge-watching a box set. This involves searching for common scene transition points across multiple episodes of a series, and using hashing algorithms on the video stream to work out when the likely sections begin and end. In the first implementation, then, the detection is run and then the user is presented with a “skip” button as a the section begins. Fully-automated skipping would perhaps be a later addition, but more work is needed yet on the code, detection of “edge cases”, and UI, and similar.

Finally, natethomas and the other Foundation board members spent some time talking about the board responsibilities: who, what, how, why. The XBMC Foundation has a legal status, and thus there are ongoing administrative, legal and financial activities around our overall direction as a project, non-profit status, trademarks, incorporation status, revenues from sponsorship and donations, approval of expenditure, taxes, PR/press, GSoC admin, Foundation membership and bylaws, internal policies, and any formal legal communications as required.

And that’s it for day one. Time to head out into the fading evening light before reconvening in the morning.

Tags: 

Beware Killer Kodi Boxes!

According to recent press, “Kodi boxes” can KILL.

Okay, to be specific (and perhaps a touch less alarmist), the power supplies on cheap, untested devices are often a bit on the dreadful side, and that’s where a risk of things bursting into flames resides. Beyond that, we assure you that the Kodi software remains friendly, docile, free-range, and free of any killer instinct. We could bore you with other tales of devices that report fake RAM size and heatsinks that rattle inside the case, but that would distract from the point of this blog post. 

Our issue with the current wave of articles is not the shock-horror, click-bait headlines, but the choice of images used. Instead of showing one of the many thousands of generic black boxes sold without the legally required CE/UL marks, the media mainly chose to depict a legitimate Rasbperry Pi clothed in a very familiar Kodi case. The Pis originate from Cambridge, UK, and have been rigorously certified. The case is from a good friend and partner of ours, FLIRC, in sunny California, USA. It’s a combination that’s as safe and unlikely to burn down your house as any Kodi device can be (indeed, neither even comes with the sort of dangerous power supplies that are in question here). We’re also super-huge fans of the Raspberry Pi Foundation, and the proceeds of Pi board sales fund the awesome work they do to promote STEM (Science, Technology, Engineering and Mathematics) education in schools. The Kodi FLIRC case has also been a hit with our Raspberry Pi users and sales contribute towards the cost of events like Kodi DevCon.

It’s insulting, and potentially harmful, to see two successful (and safe) products being wrongly presented for the sake of a headline.

In related news, you may be aware of issues in the piracy community that drives the sales of these devices. There are a number of legal actions underway, and we regularly read news of large numbers of pirate add-on developers and repo operators fleeing from these legal issues. We still see strong downloads from kodi.tv: interestingly, there’s also an increase in the rate of user churn, which is probably linked to the above and our discontinuation of support for the older versions of Android that many of these devices run. This does not concern us. Our general stance on piracy remains neutral, but fewer people damaging the Kodi name is a good thing.

Here’s the reality: if your mates are spending hundreds on something per year, and you can get it for free – If it looks too good to be true – yeah, it probably is too good to be true. You make your own choices.

Devcon 2017 Part II – Day Three

The final day of Devcon – still lots to get through, although, for the sake of some team members, we might need to speak slowly and quietly…

We started the day with a Foundation financial overview from natethomas. Even as a non-profit, volunteer-run organisation, keeping Kodi going is an expensive undertaking by the time you take into account events and conferences, hosting, legal, development hardware, and similar. This in turn led to a conversation about future logistics: we have a large team now, and it’s getting increasingly challenging to get the team together to meet, discuss, work, and socialise while we continue to make your favourite media centre software. We also want to continue to attend and increase our engagement with FOSDEM, ELC, CES, VDD and other open source and multimedia events.

Our next topic was infrastructure with kib. The Kodi systems respond to literally millions of requests per day for such things as downloads and addon updates, so we’re looking after a significant infrastructure. We have multiple servers for the forum, wiki, main web site, build server and mirroring, all of which need to be managed, backed up, maintained, upgraded. Given our recent extended forum downtime, that was clearly part of the discussion as it’s unacceptable in every respect. We need to look again at how we host our content, our architecture, and any weak points.

We then moved onto a brief conversation about addon security. This is a big topic that will need to be progressed separately: addon sandboxing to protect the core code and operating system, for example, or signing and hashing to ensure code integrity.

Tooling was our next topic, led by razee and martijn. Do we have all the tools that the developers need? Are there better ways and methods? How do we take work out of the system, perhaps through automation of some basic sanity checks? How do we make it easier for people to contribute code and get it accepted and merged?

We then moved on to forum moderation, with a discussion led by darrenhill. All forum users should be aware that we do not allow forum conversations or support threads that touch on piracy, guided by a non-comprehensive list of banned addons on the wiki. However, new piracy addons appear all the time, so we need to consider how we better maintain and publicise this list, including making it clearer to new forum sign-ups: we still get too many people who sign up specifically to ask for help with an unsupported addon, for example. The conversation then moved on to log files, and users who edit these to deliberately try to hide addons/repositories. Finally, we moved on to the sanctions we take against users who repeatedly breach the forum rules, and the basis on which we take action while trying to remain fair and transparent.

Moving on, we came back to a topic we covered earlier in the conference: whether an addon should ever be allowed to modify another addon, or whether an addon should be allowed to disable anything when it finds something that it’s decided is somehow “undesirable”. This is clearly a contentious issue. As a rule, nothing should ever break a working installation, either by changing core Kodi files or by altering some other part of a user’s installation that was already there. The current issue with addons checking for the presence of others, however, is clearly more complex as there may be legitimate reasons for such behaviour, such as a compatibility check. Expect a more formal announcement on this subject in the forums in the near future.

Our final conversation of the day, then – and the final one of the conference – was alwinus and the addon subsystem. He talked us through the current addon system, and some of the problems and limitations it presents: it’s not easily extensible, there are limitations on interoperability between addons, SQL dependencies impacting performance, and there are some inherent instabilities in the addon handling code that can trigger a crash. Simply put, there is a series of improvements proposed that will address these issues: limit SQL dependencies, remove async thread handling, cache more information, move away from dependency on cpluff.

And that’s it for Devcon 2017: time for people to head out, to airports, train stations, wherever.

Thank you to everyone for their attendance and contributions!

Tags: 

Devcon 2017 Part II – Day Two

Day Two dawns… most people are bright-eyed and ready for another day, although, if I’m honest, some people may be here more in body than in spirit…
 

LibreELEC Logo

First on today, chewitt from LibreELEC gave us an update: the installed base continues to grow, with the Raspberry Pi in different forms easily remains the dominant platform, although this is slowly declining in favour of SoC (Android stock) devices. Given the appliance nature of LE – operating system and applications – a large part of the presentation was given over to security, including automated updates and the overall integrity of the process.

GSoC Logo

Next up, a series of sessions led by our newest team members – our Google Summer of Code students (or maybe “graduates” now, given their contributions!).

Vel0city presented his work on multi-pass shaders – programs that run on the GPU to manipulate an image frame at a pixel level between decoding and display – so, blur, enhance, scale, and so on. These are particularly useful for improving image quality when perhaps the display technology has advanced significantly beyond what the source material was created for (resolution, colour depth, frame rate, etc.).

Next, yol took us through his work on touch and Wayland (vs X11) integration. While we’d had some Wayland implementation previously, this work brought it right up-to-date with native support within Kodi on Linux.

And finally, arpitn30 talked about his project to port over to Python 3 (Python 2.x goes end of life in 2020). As would be expected, this involved changed library calls, removal of deprecated syntax, and updated dependencies and versions. There are significant differences between Python 2 and 3 – they’re almost different languages – which give rise to real challenges in a cross-platform, multi-version environment. Of course, the shift to Python 3 will require rework in all Python addons, so this is a long-term migration across many different packages. If you’re an addon author, keep an eye out for further information on this topic in the coming weeks and months, as it’s not negotiable.

To close off GSoC 2017, then, razze led a conversation about GSoC 2018 – a call for more mentors, for more developers to get involved. We can bring in students, we can offer project ideas, but we need the experience of the existing developers to be successful: to help orientate people to the code and guide them through the best way to get code accepted into Kodi for release.

 

After a brief but passionate conversation about trademarks, licensing and similar, the sessions moved on to usability, and the “out-of-the-box” appeal of piracy addons versus “raw” Kodi. While we don’t provide any content, we could maybe make it easier for people to catalogue their media, perhaps with more pre-defined skin nodes or similar. We also covered interaction between addons and skins, and what the implications are of some modules either demanding or objecting to the presence of other modules, and what this means for the user experience.

Following this – in a deja vu moment for many people – the discussion moved to what we can realistically do to support DRM-protected content. People have an understandable desire to watch their legitimate, paid-for content, so we continue to explore what can be done in this area. This is likely to be a conversation that will run for some time, however.

Next up, Martijn talked about our next major release. We’ve just launched the latest point release of Krypton 17.x, so it’s time to be looking towards Leia 18.x; the code is broadly ready and stable, so it’s now a process of locking down features, freezing code, building alphas, and so on. As always, this is a major piece of logistics, so it needs to be planned and timed properly.

 

Linux (Tux) Logo  Windows Logo  Apple Logo  Android Logo

As the day started to lurch towards the finishing line, the sessions moved on to platform specifics.

Fresh from the Embedded Linux Conference Europe, lrusak covered Kodi on embedded Linux – specifically, where we are with Kodi now, and where we want to be as the SoC/embedded market continues to develop. The plethora of boards has caused immense fragmentation, and this is becoming impossible to maintain because of different approaches to windowing, rendering, and so on. There are technologies to address this, however: Linux kernel support for Atomic DRM (Direct Rendering Manager) starts to simplify the problem; V4L2 augments this further. These are not implemented on all platforms, though, so it’s sadly not that simple. The level of support, and dependency on specific kernel versions or proprietary blobs, varies between Broadcom, Amlogic, Allwinner, Rockchip, Qualcomm, and Freescale. There’s thus more work from the vendors while software packages develop in parallel: improved V4L2 in FFmpeg, Kodi changes, kernel work.

Most Windows-specific activity revolves around Kodi under UWP, which we’ve covered before. There were no major updates to report on Apple or Android platforms.

Final thoughts before we tail away… further conversations about the migration to Python 3 and how that might be phased/implemented, and anything else needed in the 17.x branch for a further point release.

 

And that’s it for Day Two – a few attendees are going to leave early today (or maybe we’ll just leave them in a bar somewhere), but there’ll still be more Devcon tomorrow.

Tags: 

Devcon 2017 Part II – Day One

Well, 2017 has turned out to be unusual, and we’re not just talking world politics. This year, we’ve managed to bring the newly-extended team together for a second time; it’s something we’d like to do more often, although it’s unlikely that we’ll be able to do it every year.

So, it’s a grey day in Czechia, with ominous clouds hanging expectantly over Prague (picture above not actual weather, sadly!). Team Kodi is assembled – developers, skinners, moderators, the Board – and has been joined by some of our newest team members, Google Summer of Code students, and a couple of key partners.

Ludi incipiant!

Keith once again played MC and opened up the session while Natethomas valiently wrestled to overcome the inevitable hotel AV equipment challenges. Our rough format for this meeting will be a partner day today (Friday) before the internal Kodi stuff takes over for the weekend.

 

FLIRC Logo 

First up for presentations, then, Jason from FLIRC took the floor. He gave us an overview of the FLIRC products, the history of the company, the rationale behind the FLIRC USB learning adapter, a demonstration of the device in action and a brief glimpse of some possible future plans. It’s amazing how excited you can get at, and how long you can discuss, what are perhaps the finest Raspberry Pi cases in the world (but maybe we’re a little biased).

 

VLC Icon

Next up, JB and Etix from VideoLAN – if you don’t recognise that name, they’re the VLC guys, who came resplendent in their traffic cone hats. Topics covered included what’s gone into VLC 3.0, code cleanup and convergence, new features. They also covered some other VideoLAN technologies, some of which go beyond VLC – Mirrorbits, for example. And we finally touched on equivalencies and common interests between the projects, and where we might perhaps collaborate more than we do today.

 

That’s it for Day One – I know that looks short, but it wasn’t. There were many side-bar conversations and parts of the presentations that we simply can’t put onto a public blog, so you’ll have to trust us on those…

Tags: