It works on some hardware and not others and appears to play nicer with our 9.0 codebase than 8.2. There is already a second iteration of patches in circulation and I'd expect further ones until a stable set are figured out. We have provided detailed feedback to the Intel driver team and will be tracking this (as we have been for months already). It is unlikely to be fixed in the initial 8.2.0 release, but hopefully things get resolved and we can add patches in a maintenance update.
Posts by chewitt
-
-
Failing that, I wonder if it would cut down the number of potential builds if you were to build at "half-way" points each time. That is an approach I've used for solving similar problems before. Then we would know whether to go higher or lower than the current commit - again picking a half way point and checking the build. It's only an idea and I'm certainly no expert in this area - just thinking aloud.
^ that's what git bisect does; you mark a good and bad commit and it starts halving the list of commits until you find the problem one
-
could not mount LABEL-LIBREELEC'
disk=LABEL=LIBREELEC not disk=LABEL-LIBREELEC .. ^ typo?
-
You can grab the driver, create a new driver package for our build-system, then include it (fixing any compile issues found) and self-build yourself a new LE image. Or.. you can go swap it for something with a supported chipset. And before you ask, there is no list of supported chipsets.
-
FYI, this is currently the best (but not complete) attempt at rewriting to modern kernel standards: GitHub - ulli-kroll/mt7610u: MT7610U driver for linux, do rework for upstream
-
It's using the MediaTek MT7610U chipset. This has no in-kernel driver and the out-of-tree driver that's being distributed (which is not updated since 2015 and ignores modern kernel standards) looks like it's been written by a 1st year computer studies student - although that's an insult to 1st year students. It is technically possible to hack and build this driver to run on LE, but I don't consider it to be of sufficient quality to be something we can (or should) support - it makes other out-of-tree drivers from Realtek look good. MediaTek need to get their sh1t together and upstream a proper driver to the kernel.
-
My $0.02 is that the /boot partition is equally susceptible to card corruption as the /storage partition. Script/automate a nightly backup and just accept that things die once in a while instead of using fragile netboot workarounds over unreliable wifi.
-
There is no maximum on the number of movies. Just get a disk .. it really doesn't matter about the brand or type.
-
The last official i386 image was OpenELEC 5.0.8 about 3.5 years ago. We dropped support to save on resources after measuring the active installed base of i386 users and finding it to be tiny. It is technically possible to still create an i386 image if you self-build with changes to re-add i386 support to the build-system. Have a look at GitHub - maideii/LibreELEC.tv-Intel-i386: Just enough OS for KODI for hints.
-
Use zomboided's OpenVPN add-on.
-
If we have to guess the GPU model any further support will require a long wait.
-
Read the lirc section of the release notes
-
We aren't fans of realtek drivers that sit outside the kernel because they are usually poor quality and problematic to maintain. It's probably not hard to build the driver, but it's debatable whether we really want more realtek crap in our builds.
-
Windows network browsing in Kodi stops working when the Kodi SMB client is set to SMB2 or higher as this is an SMB1 protocol function. We now default to SMB2 hence something changed. Zeroconf browsing only works for devices that advertise their shares over Zeroconf .. which is normally fine for NAS devices with Samba that use Zeroconf and will not work for Windows because Windows does not use Zeroconf. My honest advice .. get familiar with SSH, nano and the contents of /storage/.kodi/userdata/sources.xml and just add sources manually.
-
Our stance on support for people with banned add-ons is not negotiable. As someone with a regular presence here you should know that.
-
Intel released new firmware update for this audio problem, however its relevant for windows only
Download HDMI 2.0 Firmware Update Tool for Intel® NUC Kit NUC7i3BN, NUC7i5BN, NUC7i7BN, NUC6CAY
Hope it will be part of next LE version....
Intel firmware flashing functions will never be part of LE .. because the fcukwits at Intel only have a Windows (not Linux) flashing tool.
-
The current Samba version in Ubuntu 16.04 defaults to making NT1 (SMB1) connections even though it supports SMB2 and SMB3 - hence it works when you specify the client version from the command line. The default is scheduled to change to SMB3 in Samba 4.7 (due for release soon) and already does this in LE because we backported the change to Samba 4.6 for our codebase. You have two options:
a) Configure the system smb.conf in Ubuntu to have "client min protocol = smb2" and "client max protocol = smb3" so that smbclient connections are forced to use something higher than NT1 .. then you don't need to specify the protocol version manually.
b) Configure the Samba server in LE to allow SMB1 connections. This can be done in the LE settings GUI.
-
It's a terrible idea because compatibility lists are never maintained and are thus instantly out of date. I also strongly doubt your current box is incompatible, it's just not configured right.
