Posts by chewitt

That URL contains source packages that need to be self-compiled into an OS image: compile [LibreELEC] - Neither LE or previously OE has ever supported ISO install - only USB. Our USB/SD creator app can make the USB from the self-compiled image.

In case it's not obvious, we have no desire to support i386 hardware so without intending to sound rude; this is either something you figure out for yourself or quit the idea of recycling ancient hardware and invest in a cheap Raspberry Pi kit that will be 20x better to use.

There's method to our release management approach but people have busy day jobs. We've accumulated quite a few changes since 8.1.1 so there's likely to be an 8.1.2 beta before 8.2.0 .. but that makes zero difference to inputstream.adaptive which is already at the current latest version in the 8.2 repo (used by 8.1.0/8.1.1 releases).

Just to comment: Testing shows issues with the current iteration of patches so this probably isn't resolved until an 8.2.x maintenance update. We aren't going to rush the fix, it needs to be complete and stable before we include it.

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.

Quote from jahutchi

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

Quote from dortmunder

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.