Posts by chewitt

hkall that's nice work .. I see some bits already hit the mailing list

A1: Probably not, because there is zero consistency on LED naming over a wide range of devices and to script that feature you need something that can be consistently targetted.

A2: No, because in the past there were WeTek full-time paid staff hanging around to deal with their low-skill customers and the regular supply of support issues that came from that feature. These days it's mostly just me, and I have very limited enthusiasm for that kind of self-inflicted punishment. One of these days we'll figure out how to make mainline u-boot coexist with FAT partitions; then I'm fine to support an internal install on WP2 again.

Thanks to a side conversation while axe-throwing and drinking beer at Kodi DevCon a couple of weeks ago the latest images in my share now have a proper kernel-level workaround for the alsa speaker placement issue when using multi-channel PCM audio. The alsa channel map can now be detected/read by Kodi on the correct PCM device so magic works and audio comes out of correct speakers. It's a workaround not a proper fix (which requires some non-trivial alsa changes and more knowledge) but an improvement is an improvement. Happy Easter

Just keep an older RPi 2/3 board around for occasional 3D use. It's probably not impossible to make an LE 9.2 image with support for newer hardware but all time spent on making/testing something that ultimately few people will use is just a distraction from LE11 and encourages people to remain on LE 9.2 (when we'd generally like them to be on newer things) so I don't see staff making the effort. It's all open-source though so nothing to stop "the community" making the effort.

You can borrow someone else's computer for 5 minutes, or depending on what you want to install to, perhaps use a USB stick?

You're not mad. It should work.

So the LED now comes on with u-boot, and there might be a flash but it remains on after Kodi runs now? (previous images it would go off).

It sounds like u-boot turns the LED on (blue) but then when the kernel boots it's turned off. Hopefully this just means the GPIO polarity is reversed and this image should fix that? https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar

Can you be specific/clear. Does the LED work, or not? .. Does the keyboard work if you connect it after boot?

RPi4 wins because it generates less heat and lower electricity bills. Occupying less space and probably being more reliable in the long-term due to the massively larger number of users fixing issues in the codebase are bonus credit.

If you configured NFS shares in Kodi, it's acting as a simple client (the same as SMB). If you want to locally mount the storage and then access media in a remote share via a local mount point, have a look at the systemd .mount examples in /storage/.config/system.d/ and create one for your NFS share. Note that anything in the library will need to be re-scrapes since it's now local media not remote as before.

I've been looking around in the kernel and I see mentions of RTL8189 on a bunch of allwinner boards, but digging deeper I can only see the USB driver, not SDIO, so WiFi will need the out of tree vendor driver. I avoid adding those in my images as they break all the time and in the mid-term once we switch over to iwd instead of wpa_supplicant none of them will work anyway.

The row of up/down/left/right buttons on the remote looks a little superflous with the round up/down/left/right/ok present too, so I wouldn't fret about those. I've marked them missing in the keymap and they can always be backfilled if someone else shares them later. I'm confident the codes for the 1/2/3 key in the embedded keymap are correct as the last two digits on other keys you captured and the amremote codes I can see elsewhere match.

Thanks for confirming the LED guesswork

If you update to https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar I've reverted some patches which I think are the cause of the USB keyboard issue; please confirm back if that resolves the issue or not?

crazyturk Update to https://chewitt.libreelec.tv/testing/LibreE…arm-10.85.0.tar - I've reverted some patches which I think are the cause of the USB issue; please confirm back if that resolves the issue or not?

Have a play with https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz .. there's a slim chance the LED and WiFi chip might work now. As usual .. "dmesg | paste" and share.

You can disable auto-update (and manually downgrade to an earlier image with Kodi 19.3) in the LE settings add-on. I'm not aware of any major changes that would impact on networking. If you want assistance with VPN issues you'll need to provide some factual/technical info and logs that describe/demonstrates what and where the problem is - your unpuncutated rambling description isn't much of a clue, sorry.

Stats show 52 active installs; no nightlies or dev builds, and all are running LE 8.2 or LE 9.x builds. And yes, one shows up as an RPi3

If you flip back to an image from https://test.libreelec.tv/ or the Python38 folder in my share those images are Linux 5.17.x - and the current ones in my share are Linux 5.18-rc2. If the keyboard works in the older image there's either a defconfig change or something hinky with one of the patch series I've picked into the 5.18 branch; which narrows the scope.

Thanks for confirming the remote works. I'll have a poke at WiFi things over the weekend.

The most common cause of "SSH refusal" is old versions of PuTTY on Windows (ciphers changed, no longer compatible) but that's rarely the issue with macOS/Linux clients. Did you enable "disable password auth" in LE settings?