Posts by chewitt

Quote from @fterlife

I am by no means a programmer though so apologies if these are dumb questions.

not. dumb. but. its. complicated.

Quote from PANiCnz

Audio passthrough has stopped working on my x86 install. Was working fine on B3 and I skipped B4. Any chance this is a known issue or do you need logs etc?

Debug Logs.

Quote from @fterlife

Just an idea but would it be possible to send the HDMI signal interlaced to the tv and have the tv perform the deinterlacing? Usually TV's are quite capable deinterlace devices. I only see progressive resolutions in the whitelist. Perhaps interlaced resolutions can be enabled some other way?

Not possible as Kodi has no concept of video pass-through and only outputs progressive.

You can use a current nightly until 9.95.5 is released. There are more BT fixes in the settings add-on.

Quote from Coolzero

I have still this erorr in the log, is there a solution?

Code

2021-06-16 07:27:11.513 T:1207    ERROR <general>: DBus error: org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files
2021-06-16 07:27:11.513 T:1207     INFO <general>: LogindUPowerSyscall - UPower not found, battery information will not be available

It's harmless and simply reporting that UPower doesn't exist (which is true on LE, it's used on some generic distros). You can ignore it.

It's best to ask in the PINN forums (or RPi forums) nobody on staff runs NOOBS/PINN so our experience is rather limited.

There was some traffic on the mesa mailing list in the last couple of months about alternative GBM back-ends, which is basically about nVidia partially conceeding they aren't going to win the GBM vs. EGL Streams discussion and tweaking things on their side to reduce the differences, combined with compromise on the mesa side to allow alternatives to current libgbm; which isn't so objectionable now the EGL Streams "GBM" shim makes the differences relatively minor.

This basically allows Tegra DRM drivers to plug into mesa's userspace rendering infra which is well proven and widely supported; the shift from X11 is gathering momentum and Wayland needs mesa. Tegra V4L2 accelerated decoding is then the (non-trivial) missing link. If V4L2 compliant DRM/ffmpeg drivers are written (compliant to kernel V4L2, not some proprietary nVidia-ised interpretation) Kodi should require no changes to support Tegra boards. That's the theory anyway

Last time we looked the Tegra GPU drivers needed X11 to run, which does not align with the V4L2 oriented technical direction LE is persuing for all devices, so there is little interest in trying to support the boards.

Write this file Dropbox - bootsector.img - Simplify your life to the USB using any USB writing tool that you like (on whatever OS you are using). As long as the USB drive is okay it will nuke the partition tables and allow your OS to repartition/reformat the storage again. If it fails to write, the USB drive has a problem and it's time to bin it and get a new one (they don't last forever).

Use dd ?

chmod +x LibreELEC.USB-SD.Creator.Linux-64bit.bin
./LibreELEC.USB-SD.Creator.Linux-64bit.bin

^ first line makes the .bin executable, second line executes the .bin

Panfrost works fine on a mainline kernel, but the drivers use a range of kernel features that simply don't exist in the legacy 4.9 kernel that Amlogic ships and CE depends upon. It's a bit of a "between a rock and a hard place" situation.

Quote from Anewmission

I have 4 HP dual core 1.5g wyze thin clients.

I have a few bulky i7 machines laying around

eBay the lot and divert the proceeds to a couple of RPi4B kits

There are significant crypto changes in the kernel around Linux 4.10/4.11 which will require the driver to be substantially reworked. An attempt was made here GitHub - chewitt/ssv6051: ** NOT WORKING / DO NOT FORK! ** iComm / South Silicon Valley SSV6051 driver for LibreELEC but the conclusion of the dev who made the attempt (not me) was that the original driver is architecturally garbage and it would be quicker to rewrite from scratch (but it wasn't worth the effort).

No log = No problem

The sad state of an RPi4B here is .. 92 days of uptime since a deliberate clean reinstall (moving from 9.2.x to 10.x) and the only reboots have been when updating the OS image (self-builds, but tracking the official releases). No issues with install or boot, same as 9.2.x.

Amlogic never licensed the Linux "libmali" libs for the T820 GPU in the S912 boxes and the hack to reuse the Android libs has a perfomance impact that was borderline on older Kodi versions and not really usable with K19 and future K releases. LE avoids that by using the FOSS drivers (which are not compatible with the ancient kernels CE uses) but that's a different can of worms.

Sure. There are lots of people wanting/willing to test but nobody has shown interest in writing a driver. As the FOSS development community around Amlogic chips is miniscule (CE contributing to non-upstream vendor/BSP codebases doesn't really advance FOSS) nothing is moving forwards.

If I delete the current page the name is released and someone else can register it, and then we'll have a page that looks official that's spammed by the same shits who want to advertise piracy add-ons and VPN and IPVT services. I would also also refuse to (re)assign admin rights to someone unknown to the project. So, the status quo shall remain.