No, because the 3.10 kernel codebase is too old to sensibly patch overlayfs support in.
Posts by chewitt
-
-
Update is part of the libreelec settings add-on, and judging by the bump in users for the latest version that takes place when we enable a release for auto-update the system generally works fine - but you may run into some local issues. Our userbase keeps getting larger and we've noticed the response times for the JSON file that provides available files info are getting slower and sometimes this times out - and my guess (without debug log evidence we can only guess) that the request fails and thus update isn't triggered. There are also some traffic management controls in-place on the update server that you could run into if there are many LE devices in your network, but that's also unlikely. Kodi debug log (as the settings addon runs under Kodi) would be a starting point.
-
720p HEVC media is normally fine and lower-bitrate 1080p will work with a good heatsink, good PSU and some overclock. I'm thinking that 11Mb/sec is probably pushing the board beyond the boundaries though.
-
Index of / has image files, but not add-on files. Old versions of add-ons should still be on the server and will be visible to the OS versions they were compiled for. LE 9.0 will not run old versions compiled for LE 8.0 (when we stopped TVH 4.0 support IIRC).
-
LE ended iMX6 support at v8.2 and Kodi removed all code support for iMX6 as part of the v18 development cycle (it was broken and unmaintained). So i'm not sure what droidbox are testing, but I can 100% guarantee that it's not LE 9.0
It might be possible to reinstate iMX6 support in the future using the next-generation Kodi GBM/V4L2 video pipeline (LE10.0) but last time we checked there were still performance issues with some iMX6 configurations (non-quad ones IIRC) so it's not guaranteed.
-
Another user with the N5 Max 4/32, told me about this build: "LibreELEC-AMLGX.arm-9.1-devel-20190524165808-a41fdf1-box.img"
I don't know WTF is going on with the content of images if people are booting G12 hardware on a GX image.. but to make any progress on creating a device tree for the N5 someone needs to pop the case open and explain which WiFi and Ethernet chip(s) are in the box, and whether it uses internal or external PHY?
-
Differences in boot configuration require you to do a clean install but "backup > clean install > restore" should work fine. You will need to reset the audio config as the device names will change.
-
AMLGX is for GXBB/GXL/GXM hardware
AMLG12 is for G12A/B hardware
-
LE official Amlogic mainline images will be "arm" for libwidevine compatibility so I don't build "aarch64" add-ons for the amlgx repo. Anyone who wants to run aarch64 images are welcome to do so, but you will also need to source/provide your own add-ons. If you already installed the "arm" version of the add-on and are flip-flopping between arm/aarch64 for testing.. the arm addon is not going to work in aarch64 userspace. TL/DR; all bug reports of "no access to tvheadend" will be ignored because "PEBKAC" and it's not a bug.
-
balbes150 revert WIP: drm/meson: fix primary plane disabling · chewitt/linux@076cd72 · GitHub with drm/meson: revert "fix primary plane disabling" · chewitt/linux@8e848fc · GitHub or video only renders when the OSD layer is visible. I flagged the problem to Neil but the commits are still in his branch.
-
If you want stability/reliability on a connection always use Ethernet. If you use WiFi "all bets are off" because there are so many extra variables added to the process. Pi 3B is also known for being "okay" and not "great" with wireless performance (3B+ is evolutionarily better but not revolutionary). If you are stuck with wireless the best approach is a wireless router/bridge device that provides Ethernet to the Pi. I'm regularly working with devices that don't have working wifi drivers so I have an Apple A1rport Express for that purpose .. small, good reception on the last generations of them, and usually quite cheap on eBay - I go for the ones without a box, no cable, and look filthy - as they clean-up fine, I have cables, and they're the cheapest.
-
dts = dtb .. but you answered the Q .. thanks
-
JohnBoyz I'm interested in whether this image: libreelec-amlg12.arm-9.1.0-sdcard.img.gz has working ethernet using the x96max dts (there is no rmii variant in the image). Sound should be working.
NB: Files will be removed in a couple of hours - I'm not about to start releasing images. And do not read anything into the version number, it simply ensures that some scripts I use have a static filename to target.
-
Regarding S905x2 HDMI audio. It is noted that it only has 2 channel out. Can 5.1 channel work with passthrough?
Nope. I said 2.0 output because it has 2.0 output.
-
I'm not sure 3D will be on anyone's agenda for the Kodi GBM video pipeline - it's seen as a very niche/dead feature these days. OSMC are using the legacy kernel codebase so any fixes there aren't immediately transferrable.
-
Intel folks appear to have been on vacation (en masse) so not much activity in the last week.
-
Just to report that I don't see any improvement in playback of HEVC files compared to the previous builds.
About half of my vids (so far) don't play - just buffers to 100% and gets stuck, and others that do play have issues with ff,rw, skip seek etc causing lockups (as in previous builds).
HEVC has some rough spots but should generally play fine on GX (not G12A/B which has zero support for HEVC at the moment) hardware with 8-bit media. Most streamed HEVC media is 8-bit, but most ripped HEVC media is 10-bit and right now there is no 10-bit support in the HDMI driver. Once 10-bit support lands; then some work can be done to continue development on the HEVC decoder. There's no need for bug reports - we're engaged with the developers doing that work and we have a good and library of bad media for testing with.
-
hi
kernel 5,2 rc1 is out
When we try lima 450 mali with kernel 5,2
These images have been running lima for Mali-450 (and panfrost for Mali-T820) for some time already. Look in Kodi SysInfo.
