The LibreELEC 9.0 Alpha cycle has continued and releases for Amlogic and Slice hardware have been added additionally to the test cycle. We official support now Khadas VIM (AML S905X) and the LePotato (AML S905X) too. There are no plans to release LibreELEC 9.0 images for NXP/iMX6 hardware as support was removed from Kodi some months ago. Support will be reinstated in a future LibreELEC release and we will update you on progress with the next-generation Kodi video pipeline (which makes that possible) soon.
Alpha releases are important to the team because we cannot test every scenario and sometimes sidestep issues without realising. The project needs a body of regular testers to go find the problems we miss. Testing will be particularly important for LibreELEC 9.0 as Kodi v18 includes substantial internal changes to VideoPlayer and introduces new retro-gaming capabilities.
TEST NOTES
Our current focus is the OS core and we are more interested in hardware and driver bugs than Kodi problems. Please report the issues you find by starting a thread in the forums or use our bug tracker. Raspberry Pi users are reminded that dtoverlay=lirc-rpi has now been deprecated. Please read the infrared remotes wiki page before updating.
** CAUTION **
Alpha builds exist for hands-on testing not a hands-off experience. If you run Alpha builds you must be willing to report issues and engage the LibreELEC and Kodi developers in hunting bugs. If you have no idea what a debug log is or “wife acceptance factor” is critical, these builds are not for you. If you want to run Alpha builds please make a backup and store it somewhere off-box first. Your failure to make a backup is not our problem.
Updates since v8.90.004 ALPHA:
– updated to Kodi 18 Beta 2
– improved IR remotes at all Amlogic devices
– a lot more updates and fixes, have a look at the full changelogLibreELEC 9.0 Alpha 005 (Kodi 18 Beta 2)
To update an existing installation from within the Kodi GUI select manual update in the LibreELEC settings add-on and then check for updates; select the LibreELEC 9.0 channel and then the 8.90.005 release. To create new install media please use our simple USB/SD Creator App. The following .img.gz files can also be used to create install media or update the old fashioned way:
RPi 2/3 LibreELEC-RPi2.arm-8.90.005.img.gz (info)
RPi 0/1 LibreELEC-RPi.arm-8.90.005.img.gz (info)
Generic LibreELEC-Generic.x86_64-8.90.005.img.gz (info)
Odroid_C2 LibreELEC-Odroid_C2.arm-8.90.005.img.gz (info)
KVIM LibreELEC-KVIM.arm-8.90.005.img.gz (info)
LePotato LibreELEC-LePotato.arm-8.90.005.img.gz (info)
Slice LibreELEC-Slice.arm-8.90.005.img.gz (info)
Slice3 LibreELEC-Slice3.arm-8.90.005.img.gz (info)
WeTek_Core LibreELEC-WeTek_Core.arm-8.90.005.img.gz (info)
WeTek_Hub LibreELEC-WeTek_Hub.arm-8.90.005.img.gz (info)
WeTek_Play LibreELEC-WeTek_Play.arm-8.90.005.img.gz (info)
WeTek_Play_2 LibreELEC-WeTek_Play_2.arm-8.90.005.img.gz (info)
Posts by LibreELEC
-
-
Display More
Team LibreELEC has been rather quiet on development and priorities for a while. Silent does not mean inactive though, so here’s an update on what’s been happening and what’s coming soon:
GBM/V4L2 and DRMPRIME
Our work on Kodi’s next-generation Linux video rendering and DRMPRIME decoding pipeline continues to make solid progress and there has been some great multi-vendor and multi-project teamwork. Initial support for the DRMPRIME decoder is part of Kodi v18 (existing in parallel with older proprietary code-paths) and we now have functional “proof of concept” LibreELEC images for the following platforms:
- Allwinner (A20, A33, H3, H5) on Linux 4.18+
- AMD (radeon) using VAAPI on Linux 4.18+
- Amlogic (GXBB/GXL) on Linux 4.18+
- Intel (i915) using VAAPI on Linux 4.18+
- NXP (iMX6) using etnaviv on Linux 4.18+
- Qualcomm (DragonBoard 410c) using freedreno on Linux 4.18+
- Raspberry Pi (VC4) on Linux 4.18+
- Rockchip (3288, 3328, 3399) using rkmpp on Rockchip Linux 4.4
Kodi is one of the first major-name apps to adopt GBM/V4L2 as a framework covering multiple GPU/SoC types so this work is elevating our project profile within the Linux community. Progress is good, but also slow as we are constantly breaking new ground, and each new improvement to Kodi and FFmpeg needs to be tested over an increasing number of GPU/SoC hardware targets which have their own individual quirks. Each platform is at a different stage of evolution, but the overall trend is that we are starting to shift focus away from code creation to code stabilisation and fixing.
There are two objectives for the next-generation pipeline; maintenance and performance. Removing older and proprietary code-paths in Kodi simplifies code and makes it easier to maintain and introduce new features that work consistently over devices that share the common GBM/DRMPRIME code path. Moving to modern code frameworks like V4L2 that use zero-copy techniques allows better performance on all hardware, but this will be most beneficial to the increasing number of low-power ARM devices that need to more efficiently process ever-increasing amounts of video data.
LibreELEC 10.0 will remove support for Xorg/X11 windowing on x86_64 hardware and move the entire distro to a common DRM/GBM video framework. In the time between now and 10.0 the team will be working to achieve feature parity so nobody notices the switch 🙂
ROCKCHIP
Forward progress on Rockchip stalled in recent months because we had to stop and adapt a large chunk of the work completed on the Rockchip Linux 4.4 kernel codebase so it could start the parallel and lengthy process of being upstreamed into the mainline kernel. This burned lots of time, but work to get the Rockchip 4.4 kernel into a reasonable state (not perfect, but usable) has now resumed. Recent commits have added initial support for HDR on RK3328/3399 devices so it’s no surprise that active-install stats have started to show an increase in the number of users running test images. RK3399 support still needs work and we also need to start thinking about the install/first-run experience. It is likely that Alpha releases for Rockchip hardware run for some time, with full release targeting LibreELEC 9.2.
ALLWINNER
Video driver development essential for LibreELEC to support newer Allwinner SoC’s is also starting to drop into place. Community developer Paul Cooper (codekipper) has started to nudge the sunxi i2s audio driver towards multi-channel audio support, and Paul Kocialkowski from the Bootlin team working on player support for their current kickstarter project joined our Slack team to contribute to our V4L2 ‘group therapy’ sessions and further the cause of the bootlin driver and Kodi support (see the Bootlin blog for demo videos).
To showcase their work on the DRM driver the bootlin team have shared an LE image. At the current time their codebase is a little behind our master branch and further behind current Kodi master branch. The majority of their code has been actively developed in collaboration with our developers working on other SoC platforms, but we need to adapt their concepts in a couple of areas so approaches remain unified over multiple SoC/GPU types. We are also waiting on mali GBM libraries to be released for the H6 chip, and we haven’t done any serious work on distro packaging. Most SoCs have hardware support challenges when bumping to mainline kernels (device trees, drivers, etc.) and we expect Allwinner hardware to be no exception. So we are still some way from making firm plans. Overall platform support needs to progress further before we can start thinking about distro packaging and initial target devices.
NXP (iMX6)
Support for the proprietary iMX6 code-path used in LibreELEC 7.x/8.x releases was dropped from Kodi v18 due to a long-term lack of maintainers and it being completely broken for 6+ months due to other code changes. Our long-term plan is to switch iMX6 releases to the new Kodi pipeline and open source ‘etnaviv’ video driver. At the current time distro packaging is mostly complete and Kodi boots and runs but video rendering for GC2000 (i.MX6q and similar) devices has some limitations that mean we cannot achieve full frame rate when rendering a 1080p video while GC3000 devices (i.MX6qp and similar) render at full speed. We will most likely wait until LE10 before we releasing images for iMX6 devices again.
AMLOGIC
Maxime Jourdan (now working for Baylibre) has made great progress on a V4L2 video decoding driver and his initial patch-set has been submitted to the kernel for review. We now have functional images for GXBB (S905) and GXL (S905X/D/W) devices running a mainline 4.18+ kernel that hardware decode the 1080p video formats we need to support. At the current time deinterlaced media is handled in software which is okay (it works) but further development will be needed to support the hardware deinterlace IP capabilities. HDMI audio is working with 2.0 output and collaboration among developers working across Amlogic, Allwinner and Rockchip (which all use the same DesignWare audio IP) is starting to fill gaps in multi-channel support. The main block to public test releases is now the DRM (Direct Rendering Manager) display driver which provides HDMI support and the foundation for DRMPRIME in Kodi. Neil Armstrong from the Baylibre team has historically worked on the DRM driver pro-bono in his spare time, but with a busy work schedule progress has been slow. LibreComputer who manufacture the popular “LePotato” board (aka, AML-S905X-CC) have agreed to fund further work under their support contract with Baylibre so Neil can schedule time and move the driver forwards. The short-term goal is HDMI 1.4 support (up to 4K/30) with a separate block of work for HDMI 2.0 following once more of the kernel framework for HDR and colourspace handling (ongoing work from Intel and AMD) is in-place. This is awesome and we’d like to publicly thank LibreComputer for their open-source commitment (Da hero’s of the hour!).
Switching Amlogic GXBB/GXL hardware to use DRMPRIME on a mainline kernel was our original stretch “Plan A” for LibreELEC 9.0 but the timescales do not align. We also considered “Plan B” with a simple delay to Amlogic releases while others moved forwards, but in the end the only sensible option was “Plan Z” and we’ve dusted off the 3.14 kernel codebase for one final round. Our goal for LibreELEC 9.0 is simply to improve on LibreELEC 8.2 by absorbing some of the less objectionable bits from community releases while expanding official support to the LePotato and Khadas VIM(1) devices. At the same time we’re not aiming for perfection, because it’s a dead and deeply flawed codebase. There is a lot more to discuss on our mainline kernel plans, but we’ll save that for a dedicated blog post after LibreELEC 9.0 has shipped.
GENERIC AND RASPBERRY PI
The team are currently working through changes to move Raspberry Pi images to Linux 4.18 (the Generic image has already bumped). Our original plan was Linux 4.14 everywhere due to it’s LTS status and use with Raspbian which would benefit Pi support, but the latest generations of Intel and AMD hardware need something newer. It also became clear the Raspberry Pi Foundation and LibreELEC are mutually interdependent. We depend on Pi Foundation staff supporting and fixing issues in the latest kernels, and the Pi Foundation depends on LibreELEC needing (and proving) the latest kernels to justify supporting them. If we remained on Linux 4.14 we removed their justification and in the long-term both sides would become stuck on a ‘safe’ kernel. Generic and Raspberry Pi releases represent 85% of our active userbase so kernel choice is an important decision and it’s taken a few rounds of passionate debate to reach agreement. Helped by a clear “don’t worry folks, we have your backs!” commitment from the Pi Foundation staff, we finally reached consensus to keep moving our kernel baseline onwards and upwards.
ALPHA, BETA and KODI
LibreELEC 9.0 Alpha releases are now running and will continue for a while as our definition of Beta is “finished product with only minor bugs” so we need to have kernel bumps etc. complete before we can progress. In the past we’ve been in lock-step with the Kodi schedule and were able to go full-release within 24 hours of Kodi 17.0, but this time around the pre-Alpha stage of development has been chaotic and we’re behind on where we’d normally expect to be in our release plan. It’s likely that Kodi 18.0 will ship before we’re done with Beta testing, but the team are working hard to move things forwards.
Thanks for reading! 🙂
Source: Development Update – LibreELEC
-
Display More
The LibreELEC 9.0 Alpha cycle has started! and releases for Amlogic and Slice hardware have been added additionally to the test cycle. We official support now Khadas VIM (AML S905X) and the LePotato (AML S905X) too. There are no plans to release LibreELEC 9.0 images for NXP/iMX6 hardware as support was removed from Kodi some months ago. Support will be reinstated in a future LibreELEC release and we will update you on progress with the next-generation Kodi video pipeline (which makes that possible) soon.
Alpha releases are important to the team because we cannot test every scenario and sometimes sidestep issues without realising. The project needs a body of regular testers to go find the problems we miss. Testing will be particularly important for LibreELEC 9.0 as Kodi v18 includes substantial internal changes to VideoPlayer and introduces new retro-gaming capabilities.
TEST NOTES
Our current focus is the OS core and we are more interested in hardware and driver bugs than Kodi problems. Please report the issues you find by starting a thread in the forums or use our bug tracker. Raspberry Pi users are reminded that dtoverlay=lirc-rpi has now been deprecated. Please read the infrared remotes wiki page before updating.
** CAUTION **
Alpha builds exist for hands-on testing not a hands-off experience. If you run Alpha builds you must be willing to report issues and engage the LibreELEC and Kodi developers in hunting bugs. If you have no idea what a debug log is or “wife acceptance factor” is critical, these builds are not for you. If you want to run Alpha builds please make a backup and store it somewhere off-box first. Your failure to make a backup is not our problem.
Updates since v8.90.003 ALPHA:
– added official Khadas VIM and LePotato support
– added images to the test cycle for for WeTek devices (Core, Play 1, Play 2, Hub), Odroid_C2 and for Slice 1 + 3
– updated to Kodi 18 Beta 1 (v2)
– updated Raspberry Pi to latest 4.14 Kernel and added back the HEVC optimisations that allows HEVC playback at the RPi
– a lot more updates and fixes, have a look at the full changelogLibreELEC 9.0 Alpha 004 (Kodi 18 Beta 1)
To update an existing installation from within the Kodi GUI select manual update in the LibreELEC settings add-on and then check for updates; select the LibreELEC 9.0 channel and then the 8.90.004 release. To create new install media please use our simple USB/SD Creator App. The following .img.gz files can also be used to create install media or update the old fashioned way:
RPi 2/3 LibreELEC-RPi2.arm-8.90.004.img.gz (info)
RPi 0/1 LibreELEC-RPi.arm-8.90.004.img.gz (info)
Generic LibreELEC-Generic.x86_64-8.90.004.img.gz (info)
Odroid_C2 LibreELEC-Odroid_C2.arm-8.90.004.img.gz (info)
KVIM LibreELEC-KVIM.arm-8.90.004.img.gz (info)
LePotato LibreELEC-LePotato.arm-8.90.004.img.gz (info)
Slice LibreELEC-Slice.arm-8.90.004.img.gz (info)
Slice3 LibreELEC-Slice3.arm-8.90.004.img.gz (info)
WeTek_Core LibreELEC-WeTek_Core.arm-8.90.004.img.gz (info)
WeTek_Hub LibreELEC-WeTek_Hub.arm-8.90.004.img.gz (info)
WeTek_Play LibreELEC-WeTek_Play.arm-8.90.004.img.gz (info)
WeTek_Play_2 LibreELEC-WeTek_Play_2.arm-8.90.004.img.gz (info)
-
Display More
Alpha builds are an important part of our long-term test strategy. Our developers do high quality testing but we are small in number, don’t have every device to test with, and often sidestep problems without realising. The project needs a community of regular testers with a larger selection of hardware and more ‘human’ behaviour to find problems we miss.
Thorough testing will be particularly important for LibreELEC 9.0 as Kodi v18 brings major video changes and introduces new retro gaming capabilities.At this stage it’s too early to talk about release dates but we do want to talk about LibreELEC releasing 9.0 shortly after Kodi push their v18.0 release. It would be awesome if the time gap is small, but our priority is a stable release not fast release.
If there are outstanding issues when Kodi v18.0 ships we may hold LibreELEC 9.0 back until v18.1 or needed patches become available.TEST NOTES
The current focus for Alpha testing is the OS core. Right now we’re more interested in hardware/driver things that don’t work than Kodi issues. LibreELEC v8.90.003 is only available for Generic x86_64 and Raspberry Pi devices.
Amlogic (KVIM, Odroid C2, WeTek Play1&2/Core/Hub) and Rockchip are “work in progress” but we have visibility on developer progress and hope to start Alpha builds for them in the near future.
If you have found a problem please report them to the Forum or to our Bugtracker (forum account required).
RPi users with IR remotes may have a look at our Wikipage – dtoverlay=lirc-rpi is now deprecated.
** CAUTION **
Alpha builds exist for hands-on testing not a hands-off experience. If you run Alpha builds you must be willing to report issues via the forums and engage the LibreELEC and Kodi developers in hunting bugs. If you have no idea what a debug log is or “wife acceptance factor” is critical, these builds are not for you.
If you want to run Alpha builds please make a backup and store it somewhere safe (off-box) first. Your failure to make a backup is not our problem.
Enjoy 🙂
LibreELEC LE9 Alpha 003 (Kodi 18 Alpha 3)
RPi 2/3 LibreELEC-RPi2.arm-8.90.003.img.gz (info)
RPi 0/1 LibreELEC-RPi.arm-8.90.003.img.gz (info)
Generic LibreELEC-Generic.x86_64-8.90.003.img.gz (info)You can also download it with our USB-SD Creator tool.
-
This forum area is for users of LibreELEC community software releases. If you have chosen to run CoreELEC releases on your device please report your problems to their support forum: CoreELEC Forums where people familiar with their codebase hang out. Posts on CoreELEC will be closed and moved to an "unsupported" forum to ensure the focus of support here remains on LibreELEC users seeking help with LibreELEC software.
-
This morning LibreELEC board member @xe received written notices from GDPR-2 and GDPR-1 demanding their GDPR Article-17 right to have all personal information held by the project deleted from our systems. They have further requested we remove all of their forum posts and purge any data stored on team webspace. To prevent further creation and propagation of their data while we clarify our GDPR obligations and investigate what technical steps may be required, we have suspended their accounts.
It's a shame to see this level of deliberately awkward activity, but we aren't going to fight their decision. Other forks in our ecosystem (Lakka, OpenPHT, PlexEmbedded, etc.) exist happily as derivatives of LibreELEC and their team members regularly and proactively contribute to our codebase. From the outset CoreELEC proclaimed total independence and leading team members have repeatedly stated they will not contribute back to LibreELEC. We don't really care that CoreELEC exists and we've been ignoring derogatory statements for the sake of peace, but continuing to host their drama and noise in our forum has zero upside for LibreELEC if they refuse to participate in our project. It is unclear whether other CoreELEC contributors with presence in our forum will request the same trip to /dev/null or would prefer to retain their status and become supportive and helpful participants to our project.
The Board
-
Following the recent board election we started the important work of defining project bylaws. We also started to review project policies, some of which are long-running and documented but need revising, while others are more informal and need to be written down. One of those policies is our definition of a LibreELEC Community Build and the responsibilities of Community Build creators.
Our requirements are simple and now apply retrospectively to all Community Releases. They can be read on the Wiki here:
Minimum requirements for a LibreELEC Community BuildRecognising what is/is-not a LibreELEC Community Build and defining common-sense rules allows the project team to focus on supporting community developers and the users they serve. We often provide dedicated sub-forums and webspace to help builders distribute and support their releases without incurring personal costs. In some cases we also hook their releases into core project assets such as the update mechanism and our add-on repository.
In the next week we will reach out to a small number of community developers identified as non-compliant. If they are willing to work with the LibreELEC project team and address discrepancies we will be happy to allow continued use of our infrastructure. If they are not, we will be encouraging them to provide their own.
The Board
Source: Community Builds – LibreELEC
-
Team voting has concluded and the following nominees are elected to the project board:
- cvh is our forum admin and resident DVB/Tvheadend expert
- davu is a forum super-moderator and enthusiastic bug hunter
- lrusak has been the project technical lead over the last two years
- milhouse is well known for his bleeding edge community test images
- xe is our IRC channel admin and a FOSS advocate
In statistics: 22/22 team members cast their vote. 1/5 of the board are Canadian, 2/5 are German, 2/5 are from the UK. 3/5 board members are also Team Kodi members. 4/5 board members come from the original group that forked from OpenELEC. 5/5 board members have contributed something to our GitHub repo. 3/5 board members (cvh, lrusak, milhouse) will serve a 24-month term while 2/5 board members (davu, xe) will serve a 12-month term.
Thanks to all team members for voting (and agreeing to be team-members) and congratulations! to our new board members 🙂
-
LibreELEC (Krypton) 8.2.5 is now available with updates to Raspberry Pi firmware to address issues seen with the initial firmware release supporting the new 3B+ hardware (which also affected the Slice box). We also bump both nVidia drivers in the Generic x86_64 image, resolve an MCE remote problem, add support for the WeTek Pro remote control unit in WeTek images, the Allo DigiOne DAC in Raspberry Pi images, and updated u-boot in the Odroid C2 image now supports mild overclocking to boost performance.
See detailed changes on GitHub.
Enjoy 🙂
-
On Tuesday 10th we called time on the initial registration of LibreELEC team members and nominations for the board. In total there were 22 people who signed up and 7 who accepted nominations. Our independent helper has emailed Condorcet vote links so members can rank nominees in personal order of preference and cast their vote. We have allowed 10-days for voting, but if all votes have been cast sooner we will end the election and announce the results.
The team has decided to elect a five-person board, and to stop us replacing the entire board at each election the three highest ranked board members will serve a 24-month term while the next two members will serve a 12-month term. This means that each year there will be an opportunity for board changes, but we also ensure continuity.
The first priority for the board will be creating bylaws for the project and then running a membership vote to accept them. The second priority is to agree and assign roles and responsibilities to the board members and establish any other management structures the project deems to be necessary (technical steering committee, infrastructure admin team, etc.).
Next update will be to announce the results!
-
In the last 18-months we invited many developers to collaborate and work in our extended team, but not many non-developer helpers. Developers doing development is essential, but non-developer contributors have an equally important role because these are the volunteers who manage forums, respond on social media, and often volunteer to help with less exciting admin tasks.
Over time our developer/helper imbalance has contributed to the project depending on a couple of long-term contributors and people have raised issues with the way things operate (claims of dictatorship, external influences, etc.) which has led to friction and even inspired a minor code fork. The dictator claim is part-true because the project runs as a meritocracy where those who step-up and take initiative are ultimately those who create outcomes and set project direction. Another factor is “spectator syndrome” which often occurs when a project grows rapidly but the number who take initiative grows at a slower pace. In the last year situations where many can see that a task needs doing but everyone waits for someone else to do it have become frustrating. Tasks become concentrated in a few regular (older) hands, and recent invitees who lack a long-term perspective on how the status-quo evolved perceive those hands to be dictators.
Recent Slack debate concluded that we aren’t being true to our original vision for governance so things must change. To drive shared responsibility and checks/balances our first action is to finally form an elected board. For the next week the current ~95 people in our Slack team are invited to declare themselves as formal team members and propose nominations for an initial board to represent them and write initial bylaws. An impartial observer to the project is helping us to register members and then run a Condorcet vote on the list of accepted nominations.
This is a long-overdue but exciting move. We will be publishing updates on the team-member and board nominations process as things unfold as it’s important we keep you all informed.
Source: Board Election 2018 – LibreELEC
-
Display More
The project needs help. We would like to start releasing new images for a number of Amlogic and Rockchip devices including long talked-about (and needed) generic catch-all images, but this has a major impact on project resources. LE 7.0 released 8x images, LE 8.0/8.2 has 11x images, and LE 9.0 increases output to 22x images with another increase on the horizon once Allwinner support becomes possible and NXP (iMX) support is re-added. Increased output impacts our build server/slave capacity and requires us to rethink how our images are tested. It also affects our human resources (the other kind of build slave).
To outline the problem:
- If we build images manually we have enough build-slave capacity to handle 20-25 images
- If we build 20-25 images manually the human slaves burn-out and quit the project
- If we build 20-25 images it’s impractical for the team to test all images before release
- If we build images automatically we save the sanity of the project staff!
- If we build automatically and crowd-source testing we must release untested images
- If we want confidence in untested images we need to crowd-test frequently, i.e. nightly images
- If we want to build 25+ images nightly, we don’t have enough build-slave capacity
- If we build less frequently we gain capacity but lose confidence
- If we add NXP and Allwinner images in the future we will have 35+ images!
- We also need to build and test many of the GitHub pull-requests we receive
- We also need to build and test new devices in development branches
- We also need to build and test full releases (less frequently, but most importantly!)
- We also need to automate build and test for 60x add-ons over 8x CPU/ARCH combos
The team have been experimenting with Jenkins continuous-integration/automation and nightly builds (with 11x images and add-ons) and we have a core workflow figured out. It shows our cross-compile build-system needs core changes to become more parallel and compute efficient, but this is complex work and those improvements will be long-term.
In the the short and mid-term we need compute capacity. It currently takes ~3 hours to create a single LE image using a single build-slave (16x CPU Cores, 32GB RAM, 15k-rpm disks) and while utilisation improves building many images in parallel, image creation time slows to 8-9 hours. TL/DR: We do not have the capacity to provide frequent images (to catch issues early and build high confidence in crowdsourced testing) and handle the ad-hoc workload from development builds, the creation of official release images, and sustaining work on a large number of binary add-ons.
How can you help?
If you are able donate and host build-slave hardware (minimum 8x Cores, 16GB RAM, 640GB of SSD or 10-15k drives) with proper power, cooling and connectivity, or can make a one-time or recurring annual donation that allows us to rent build-slaves from a reputable hosting provider, we need to hear from you. In the mid-term we will need at least two additional build-slaves so we need to find multiple sponsors.
The team also needs regular access to one WebEx, GoToMeeting or similar web-conferencing account to host monthly team calls with an average of 15-20 people. Humans talk better than they type and we need to boost our communication during a time of growth and change. Key team members reside in countries where free VOIP services are routinely blocked so business services (which are not) are required.
In both cases the project will be happy to publicly credit and acknowledge the brands and people who help us out, if recognition is desired.
contact@ our domain.
Thanks! 🙂
-
LibreELEC started out in March 2016 with a single combined website/forum/update/release server which was simple and dirt-cheap to run, but we quickly outgrew it, and to be frugal with limited funds our services were dispersed over several cloud providers and team-members who could host from home.
Over the next year having servers in many different places became complicated to manage so we started to look for a long-term hosting partner. Digital Ocean were one of the names on our short-list, and after we approached them to explain our needs and sparse (user funded) budget, they responded with a generous offer of 12-months hosting credit.
That 12-month period has now expired, and from tonight we are responsible for hosting fees again. Spending $0.00 over the last year has enabled us to experiment with hosting configurations as we migrated a number of servers and services back into a common platform and learned what we need to secure, manage and run the infrastructure of the project. It also created financial breathing-space; allowing us to start on some other project objectives earlier, and our funding horizon extended from a few months to something more distant.
For this valued contribution to our project. Digital Ocean, we thank you!
-
Display More
Team LibreELEC celebrates its second birthday (and international Pi-Day) with the release of LibreELEC (Krypton) v8.2.4 which brings minor bug-fixes and new firmware to support the Raspberry Pi 3 Model B+ hardware announced this morning. Highlights of the new Pi hardware include:
- A 1.4GHz 64-bit quad-core ARM Cortex-A53 CPU
- Dual-band 802.11ac wireless LAN and Bluetooth 4.2
- Faster Ethernet (Gigabit Ethernet over USB 2.0)
- Power-over-Ethernet support (with separate PoE HAT)
- Improved PXE network and USB mass-storage booting
- Improved thermal management
Improvements to WiFi stability and performance on the 3B+ are noticeable. In private testing over the last two months we have been able to stream typical HD media over a 5GHz network at 105Mb/sec without the buffering and dropouts seen with the previous (2.4GHz only) model, and even 2.4GHz speeds reached 50Mb/sec where the 3B struggled to reach 35Mb/sec. Ethernet is still the best option for playing larger media files and the leap to gigabit Ethernet makes a positive impact on playback start times, even with throughput capped at 330Mb/sec by the internal USB 2.0 bus. The 1.4GHz CPU boosts 1080p HEVC decoding and general Kodi GUI performance, while thermal design improvements reduced our normal operating temperature despite speed increases and sdram overclock, although a small passive heatsink or case like the Kodi flirc case (which incorporates one) is still a good investment.
Our verdict: The 3B+ is not the fastest Single Board Computer (SBC) device available but raw speed has never been the main selling point of the Raspberry Pi, and Linux/Kodi support remains superlative and the key differentiator against other SBC’s that look attractive on paper. Overall the Raspberry Pi 3B+ provides a positive performance boost for Kodi, and we are confident the Model 3B+ will replace the outgoing 3B as the #1 popular SBC to run LibreELEC on.
MEDIACENTRE & RETROGAMING KITS
Our Shop page has been updated with links to Kodi mediacentre and Kodi retrogaming kits from The Pi Hut that are shipping with the new 3B+ hardware. Purchasing kits or even a plain-board upgrade or starter kit via the affiliate links on the shop page is an awesome way to support the education mission of the Pi Foundation (funded through board sales) and LibreELEC as we receive a small referral commission that goes towards our current funding goals.
ANYTHING ELSE?
The 8.2.4 release is 95% about supporting the new Raspberry Pi 3B+ but Pi firmware updates benefit all Pi users and a fix in the LibreELEC settings add-on solves a size calculation issue when creating backups on external storage. We also bump Samba to solve another major bug-scare although it is unlikely LibreELEC users are running a problem configuration. As with other recent updates; changes are limited to keep the focus on LibreELEC 9.0 and to avoid breaking things. Full details of the changes are on GitHub.
Happy Birth/Pi-Day! 🙂
-
Display More
LibreELEC 8.2.3 is released to change our embedded pastebin provider from sprunge.us (RIP) to ix.io (working) so users can continue to submit logs to the forums through a URL without copy/pasting text or direct uploading log files. This is our preferred way to receive and read your log files so if you are not familiar with using the paste function please read this wiki article to find out how. The 8.2.3 release also solves an issue with continuity errors on USB DVB adaptors that has been troubling some 8.2 users for some time; kudos to user @jahutchi for tracking down the problem kernel commit. We also address a long-running crashing issue with Intel BayTrail hardware that needed some users to force max_cstate in kernel boot parameters, and for bonus credit users with an Intel NUC equipped with an LED can fiddle with the colours, as we backported the LED driver from our master branch.
See detailed changes on GitHub.
SPECTRE/MELTDOWN
The Spectre and Meltdown security vulnerabilities have generated a lot of press in recent weeks. Raspberry Pi hardware is not affected. Amlogic hardware does not appear to be affected. Devices that run our Generic x86-64 image are considered vulnerable. However, there are no plans to address either issue in the current 8.2 release series. Why? .. because patches for these issues are still evolving and lots of testing will be required and that effort needs to focus on our active development branch. Both issues are also moot for LibreELEC because current exploits either require a browser (which we don’t have) or local console access; in which case you are already the system root user and there’s really no need for those exploits.
WHAT’S NEXT?
Having previously claimed 8.2.1 then 8.2.2 would be the final 8.2 release we’ll stop making predictions and just see what happens. Kodi Leia is in a fluid state at the moment so the Alpha release milestone has moved back to April. There are no Kodi Krypton changes on the horizon (developers all switched to Leia months ago) but if we accumulate further nip/tuck fixes for reported issues or something exciting comes along we will consider another 8.2 maintenance release to fill the void.
Enjoy 🙂
-
Display More
LibreELEC 8.2.2 is a minor maintenance release to resolve an ffmpeg issue that allows the legions of 3D movie fans (both of you) to watch them again. It also fixes an issue with the WeTek Core after recent WeOS updates have been installed, adds support for the 2nd generation of RF remote from OSMC, and disables the flashing blue ‘activity’ LED on the Odroid C2 that most users find annoying. That’s all it contains. No package bumps or driver or kernel changes are included, because at this late stage of the release cycle we have no desire to go fix things that might add new bugs.
See detailed changes on GitHub.
AUTO UPDATE
Auto-update will be postponed until December 27 or 28 to ensure project staff focus on their family and friends over Christmas, not forum posts. Until then older releases can be updated to 8.2.2 using the GUI manual update function in the LibreELEC settings add-on.
Happy Holidays!