Articles by Prof Yaffle

DevCon 2019 – Belgrade – Part III

So, here we are, the third and final day of DevCon 2019. It’s likely to be a short list of topics this morning before some people head home while those who remain use the time together to write some fabulous code. So, let’s get straight to business.

 

We kicked off with kwiboo and jernej (from the LibreELEC team) talking about HDR support on Linux. This goes way beyond Kodi, as it’s kernel-level work to improve GPU support; this then ripples through the operating system before finding its way to Kodi via V4L2 and ffmpeg. We’ve been working mostly with the Intel team to complete support for their chipset, but there’s also basic work in place for Allwinner, Amlogic and Rockchip. This means that we’re well on the way to having a common implementation across all major chipsets that are likely to be running Linux. The industry-wide, concerted focus on V4L2 (driven significantly by Google/ChromeOS) also means that we can finally strip away large chunks of proprietary, vendor-specific code as all of these chipsets move to a common, standardised API model. We’ve grudgingly tolerated these for a long time, but they make maintaining and updating functionality so much more difficult when you need to consider dozens of different code paths, so we’ll be glad to see the back of them.

A couple of topics that took some time but didn’t really make it to the final sessions, so perhaps we’ll come back to them later: roles and responsibilities within the Board, the overall Kodi architecture and how it could be improved, potential for web browser support in Kodi. Just headings for the moment, so don’t get too excited.

Following this, we spent a chunk of time on introspective activities: admin rights, system and application access, social media access, password lockers, two-factor authentication, and similar. We also talked about Team matters: new members, absent friends, acknowledgements. Maybe not really interesting to the outside world, but still stuff we need to worry about if we’re to keep everything running smoothly.

And now it’s time for what a room full of developers (“a segfault of programmers”, perhaps?) with laptops does naturally. All around me, I can see screens scrolling as code compiles, the brightly-coloured syntax highlighting of IDEs, the transient flash of windows and terminal prompts as people cycle between them. The mob is talking animatedly about CODECs, rendering planes, operating systems, APIs, kernel calls. In the distance, a heated debate begins about the relative merits of Linux distros. There’s a constant murmur of noise, the combination of conversation, keyboard taps and error sounds. The mood for the rest of the day is set… let’s hope no-one breaks anything important… ¯\_(ツ)_/¯

So, that’s it for this year. Thanks for listening, and I hope you’ve found these posts informative. More than that, though, thanks for continuing to support Kodi!

All the best,

Team Kodi.

Tags: 

DevCon 2019 – Belgrade – Part II

Morning, all. It’s a beautiful day here, and we’re just waiting for the last few latecomers to arrive before another day of DevCon…

 

We kicked off with Python 3, following on from yesterday’s conversation. The general consensus was to get this merged and live with any minor breakage – we need to get this done, and can’t wait for absolutely every add-on to be updated before we merge. This shouldn’t be a surprise to anyone, after all.

The conversation then quickly shifted to sarbes talking about features that would make life much easier from a Python developer’s perspective. These are really around how the core code handles items, lists and displays, and how this could be modified to improve the user experience (e.g. pagination of long lists). The obvious affect is on lists of Internet content, but it would also improve PVR/EPG display, searching, and others. Similarly, allowing add-ons to specify viewtypes or just know more about what views the user prefers would make things more consistent and usable. Other ideas included subtitle support for use within add-ons, and some kind of URI mechanism so an add-on could transfer a path from one Kodi instance to another – this would allow you to move playback from your ‘phone to the TV, for example.

Next up, jimcaroll stepped up to talk about Codegenerator, which is a core part of Kodi’s Python (and, in theory, other scripting language) API, auto-generating the C++ API code as required. The main purpose of this is to reduce code size and improve maintainability, but it could potentially scale to give a more flexible, standardised approach to supporting multiple different types of external module. Only a concept, but that would open up huge possibilities for add-ons in C#, JavaScript, Groovy and many others, bringing very different functionality, security models, and scope.

This was followed by an update on tvOS by kambala and fuzzard. Much of the Apple-specific code has been floating around for a while in various forks and branches, so this is a more concerted effort to bring it all back together, update and augment it to form a complete package for the Apple TV 4. Still a work in progress, but getting closer.

Next up, lrusak took the stage to lead a session on how platform specifics can block or delay overall development – for example, when a pull request affects all platforms but there’s some obscure issue on one particular operating system. Older versions of operating systems may come with different libraries or different development toolchains; different platforms might diverge totally or even miss out components that are business-as-usual on everything else; API calls can behave slightly differently even when they shouldn’t.

So, should we hold everything back because of one platform? Should we hold back all platforms because, say, an older but still maintained (e.g. LTS) OS release can’t support some aspect of newer functionality? Should we merge a change if it compiles on all platforms except one, effectively breaking that platform until “later”? This isn’t an easy issue: ultimately, we want to get new functions and fixes out there, and that may mean living with some dead code and platform-specific workarounds in the meantime; alternatively, we simply freeze older platforms at a previous Kodi release, and move on (as, indeed, many other application developers do). As always, though, if you’re a developer who could help here, you know where to find us…

After a break for lunch, kib and keith kicked off a conversation about Foundation responsibilities and costs – some activities are legal in nature, many of them administrative, all of them important. As a registered non-profit organisation, we’re obliged to submit certain paperwork on an annual basis to keep that status along with US tax declarations. Forget this, or get it wrong, and we face losing our status and either incurring significant taxes or else paying lawyers to re-submit and regain it – neither scenario being something we want. As such, we have an ongoing task to better document what people do and highlight the imperative tasks within that list: even as a bunch of volunteers, there’s a degree of professionalism required behind the scenes, and that means sometimes paying for help.

Time to return to more technical matters: jimcarroll once again took the floor, this time to talk about threading in Kodi. Given the history of Kodi, there was a lot of platform-specific threading mechanisms. That creates complex code, with dependencies and checks that just get in the way – so, can we collapse it down into a more platform-independent model, or, at least, a minimal set of variations? It turns out that you can slim down to two main models: POSIX and Windows, and that’s where the work has been heading. Some code will still need variations, though, although other code can be collapsed still further into newer, more standardised threading mechanisms that have been implemented on all platforms since the original code was written (e.g. as implemented in C++11).

Bringing the afternoon to a close, then, jimcarroll stayed on his feet to talk about DI – dependency injection. This is a mechanism to move away from a monolithic main() routine that directs all other application activities, and instead having a suite of dynamic dependencies between modules that are resolved at runtime. In this instance, the code can declare a constructor that has a dependency on some other component without explicitly knowing about that other component when the code is written.

 

And that’s it for Day Two. A few more topics to roll over until tomorrow, along with a hackathon while everyone is together – but, until then, that’s all for now.

Tags: 

DevCon 2019 – Belgrade – Part I

Another year passes, and here we are once again, locked in a windowless room to discuss all things Kodi-shaped. Genuine thanks to the generosity of our sponsors and users – that means you, you lovely people – whose donations make these meetings possible. Old faces, new faces, guests – these events really do help us to come together, share ideas and shape the direction of our favourite media software.

So, where are we? Well, this blog post comes to you from Belgrade, the capital of the Balkan state of Serbia, at the crossroads of central and south-east Europe. A city of some 1.25 million people, Belgrade has a long and turbulent history: the area has been inhabited for some 8,000 years, and has been home to, or part of, the Vinča culture, Celts, the Roman Empire, Slavs, the Bulgarian Empire, the Hungarian Empire, the Ottoman Empire, the Habsburgs and Yugoslavia. 

On with the show…

 

After the usual round of introductions, kambala opened the show with a session on crash reporting: whether and how we could collect more crash logs by making it semi-automated or just generally easier (“Kodi has had a problem, would you like to send a report to the developers?” sort of thing). If we can get better insights, particularly into “silent” crashes, then we can get to work on eliminating bugs without waiting until someone gets annoyed enough to report it. Of course, we need to balance data volumes, human workload, user privacy, platform/component-specifics, and several other factors before we go down this road, so it isn’t something that would appear tomorrow.

Next up, DarrenHill gave an update on forum activity and moderation. Overall, we’ve got a solid, worldwide team of moderators and a good suite of supporting tools that have had a significant positive impact on volumes of spam or undesirable posts. There’s more user-led engagement around what we can and can’t support on the forum; we’ve improved how we can notify our users when there’s an upstream problem (e.g. with metadata providers) that might cause issues with Kodi; spammers are either blocked at source or removed from the forum very swiftly. What we’re perhaps lacking, though, is more diligence around the wiki as a source of help – keeping this up-to-date as Kodi continues to grow and improve. As usual, volunteers are always welcome.

Our 2019 Google Summer of Code student, gusandrianos, took the microphone next to talk about his work on multi-pass shaders in RetroPlayer. Shaders are GPU routines that handle scaling, colours, lighting, shading, etc., and are used in RetroPlayer to change the look-and-feel of games as individual frames are rendered: pixellation, colour saturation, scaling, video effects, and similar. More information can be found via the GSoC website here.

Keith then stepped up to lead a discussion about Kodi’s trademark policy and how we work with community groups that wish to use our code and/or branding.  This covers projects which effectively bundle or build Kodi for specific purposes (e.g. LibreELEC or Debian) as well as complete rebranding (e.g. OSMC, SPMC). What we’re really trying to do is protect our intellectual property while being as easy to work with as we can be: we’ve probably been a bit heavy-handed in the past, and this isn’t helpful when people are simply trying (for the most part) to do the right thing. This conversation then led into how we include more “stakeholders” into our conversations – people who aren’t team members, who maybe aren’t specifically contributing to Kodi, but who are still doing interesting, relevant things that should be embraced. The conversation also covered “best practices” and how we can more easily advise people what they can and can’t do, or under what conditions.

The afternoon session kicked off with Keith giving an overview of Kodi’s financial position – where our money has come from, where it’s gone back out to, what we have left. Changing financial regulations around the world also mean that we need to re-assess our bank account setup, specifically in terms of how we keep “local” accounts to receive donations and pay expenses in e.g. EUR when we’re incorporated in the US.

Within the team, we use Slack extensively to talk to each other on both broad (e.g. “moderators”) and narrow (e.g. “HDR on Windows”) topics, so we had a conversation about all the channels we have that team members may have missed. We also talked about external channels, which we have so we can invite guests, bridge to IRC, and similar. If you collaborate with Team Kodi in any way and would find this useful, please let us know and we’ll set something up.

Next up, yol and DaVu led a conversation about how, now we’ve completed the move, switching bug tracking from Trac to GitHub Issues has worked out. In general, it’s working well, although we need to tighten up how we tag issues to both make sure they get routed correctly and, ultimately, to ensure that they get closed off once complete. You can find the current list of open and closed issues on our GitHub code repository. We’ve adopted a similar process for tagging pull requests, although we clearly need to improve our approach for notifying, reviewing and merging PRs given the backlog we’ve built up.

We talked a little about the European Union’s General Data Protection Regulation (GDPR) and what this means for us – specifically, the forum, as that’s arguably personally-identifiable information. Generally, we don’t aim to collect such information, and people’s posts are made publicly and thus outside of the scope of the legislation. However, there are still perhaps some tweaks we can make to ensure all “fingerprints” are removed should someone ask.

The next topic was around the vision for Kodi and how it fits into the streaming world we find ourselves in. The conversation was started off by da-anda, reflecting how we, as individuals, have seen our viewing habits change in recent years. This is a big topic, as there are as many political issues as there are any others: as part of the battle between themselves, the “walled garden” content providers fiercely defend the ‘user experience’ via their specific interface and applications. This obviously has real implications for any attempts to bring streamed content into a combined library view.

The conversation moved on with a conversation about add-ons – specifically, how they’re listed and shown, which is currently best summarised as “in a long list, not all of which will work for everyone even if you know what they might be for”. Can we group them? Can we tag them? Who would, how? We also touched on use cases – how clumsy it is to add your own home videos or similar content, for example – and also how else people do or could use Kodi. And we also talked about the implications for core developer time (both as mentors and programmers), and our constant need for more people who are motivated and interested in contributing significant features to the project; if nothing else, it’s futile to have a roadmap or list of features if we then can’t actually implement them. Kodi is a fantastic playground for experienced C++ developers and for those who wish to develop these skills; you don’t need to be a video guru either, as there’s an awful lot of code around the core player/renderer routines. Go on: you know you want to…

The day continued with a1rwulf and the work he’s been doing on metadata and database storage. This is major re-work that impacts large pieces of code throughout the application, so merging it needs to be done carefully. However, it brings about significant performance improvements, scales to large databases better, and brings new functionality around music sources and playlists. Some of these functions might better implemented as binary add-ons so they can be ported to the core application sooner rather than later – the benefit of taking a more modular approach.

Rounding off the session, then, garbear introduced a discussion around Kodi versioning which quickly led into plans for Kodi 19 “Matrix”. New features or capabilities notwithstanding, Python 2 goes end-of-life on New Year’s Day 2020 – the clock is literally ticking down – and that gives a growing imperative to release the Python 3 version of Kodi into the wild. There are, of course, other issues to address and other code to include before we can release, and a final check that Python 3 doesn’t break more than it solves, so it’s a balancing act now.

 

And that concludes our first day. As the sun sets on Belgrade, it’s time to head out into the Balkan night in search of beer and something to eat. Okay, mostly beer.

Tags: 

Kodi “Leia” 18.4 Release

Another couple of months have passed since we last pushed out a release, and so, in our ongoing efforts to produce the best media software in the world, it’s time to squash another few of those more irritating bugs. Usual rules apply: don’t expect any new features, don’t think that this will change your life, it won’t make you richer or more attractive, but it will hopefully be more stable and usable for people who’ve been victims of any of these bugs.

So, what have we done? Well, you can find a full summary of closed pull requests here, but the summary would be…

Interface

  • Fix Missing text when sorting from inside addon
  • Clear/save focus-history when leaving window with focus on parent folder item
  • Picture slideshow fixes (Estuary)
  • Subscribe to controller install events (games)
  • Fix radio button text length (Estuary)
  • Fix season/episode formatting for video addons (video)
  • Don’t consider display mode ids constant (Android)

Playback/Display

  • Fix PlayMedia builtin for playlists (.strm) and “artists” smart playlists (music)
  • Fix PlayMedia builtin for smart playlists and playlists (music)
  • FFmpeg: Bump to 4.0.4-Leia-18.4
  • Load program from stream property without using streaminfo (video)
  • Fix initialization of AVD3D11VAContext structure (video, Windows)
  • Fix TS resume point, related to PR16314 (video)
  • Fixed memory leak, fixed segfault (video, Linux)
  • Fix PAPlayer to handle passthrough for TrueHD (audio)

PVR

  • Fix component dependencies
  • PVRRecordings: Prevent concurrent calls to video database

Other/General fixes

  • Use first protocol from add-on in add network dialog
  • Use exact matching for protocol in file+dir factories
  • Use of absolute paths in combination with hosts in URLs
  • Fix file times for vfs addons
  • Fix + sign HTTP folder
  • Corrections to filesystem CircularCache initialization and termination
  • Controller fixes
  • Delete stream details when video info is refreshed
  • Do not attempt to further resolve plugin paths for failing entries
  • Revert “fixed: We should always update stream details from player…”

Many – indeed, most – of these fixes are hidden deep inside Kodi and really shouldn’t be obvious to most people; unless you’re doing something that regularly hits one of them, you’ll really never notice. That said, they’re all real bugs, and real fixes, so thanks as always to all who found a bug, took the time to report it and, in some cases, provided a fix.

The full v18.4 changelog can be found in our GitHub milestone. If you want to read back on what was actually changed in v18 itself, you can find the corresponding articles in the blog posts – Kodi 18Kodi 18.1Kodi 18.2, and Kodi 18.3.

As usual, Kodi roll out on different platforms (notably, Google Play and the Microsoft Store) varies due to circumstances outside of our control. It may thus take a few more days, so just stay tuned.

Kodi “Leia” 18.2 Release

Just when you thought we were all having a rest for Easter, here’s some surprise news for you: Kodi “Leia” 18.2 is ready to roll. The sun is shining and the sky is blue here in western Europe, and we’re all tied to our keyboards to bring you the latest Kodi loveliness. We’re kind like that.

In keeping with the 18.x maintenance release cycle, this is a bug fix release, with no real new functionality. What’s worth noting, however, is how we’ve identified and managed the bugs this time. We’ve always valued high-quality bug reports, and, for this reason, for 18.x we implemented an issue template and an automated verification system in the GitHub issue tracker. This makes the bug reports more complete, and gives the Kodi developers a better chance to pinpoint problems more accurately and fix them more quickly. The aim is to solve the problem of waiting for proper full debug logs, samples and suchlike, hopefully saving a lot of time and getting issues resolved more quickly. Hopefully, you can see the results of this new process in the 18.x bug fix releases.

For this 18.2 release we are also grateful to have received many code contributions from outside Team Kodi. With this help we were able to fix performance and dependency regressions in our GLES rendering path. Similar fixes were contributed for the AML platform, which really hasn’t received much love over the past years.

VAAPI on Intel has gained some corrections for interlaced content that toggled interlaced flags during playback, and therefore caused stutter by reconfiguring the decoder.

Amongst other things, work has continued on Kodi’s music experience: database access speed has been optimised as well as improved import functionality. Similarly, there have been fixes and improvements across all aspects of PVR, with a couple of particularly nasty bugs sent on their way.

You can also find a huge number of improvements for the Android platform. Because of the automated Google tests done in the Play store, we were able to track down and resolve a lot of issues revealed by those “drunken monkey” tests.

Beside all the fixes, we have introduced a Codec Factory (Android only) where power users can configure HW-Decoder usage in a fine-grained way. Most box sellers only provide usable codecs for formats which they use to sell content. Other format support tends to be poor, and therefore a configurable heuristic-based codec and video dimensions was added. The settings can be configured by the user in human-readable and writable XML format. More information can be found in the related pull request.

We will continue to work on Leia: an 18.3 release will be drafted once we have important fixes for this release. In the meantime, development on version 19 M* has begun. We will officially announce its new codename shortly. A small spoiler: “May the force be with you – always”. But this time we will switch universes (and here’s another hint: you might find it on GitHub already if you know where to look…).

The full v18.2 changelog can be found in our GitHub milestone. If you want to read back on what was actually changed in v18 itself, you can find the corresponding articles in the blog posts – Kodi 18Kodi 18.1.

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: