Posts by chewitt

Quote from VLouis

So if it set only a few second to wait, when expired, the LE will continue to boot even without network connection.

That's normally true, but when you enable the wireguard.service you add hard "after ntp" and "before kodi" dependencies to the boot sequence and because there is no valid network connection the ntp check never completes and thus the Kodi service which makes the wait-for-network check is never reached.

The only way I think you can workaround this, is to stop/disable/mask the embedded Kodi startup systemd service (which runs an embedded shell script) and replace it with a modified service and script that's enabled/run from from somewhere on /storage; with the modified script containing logic to start wireguard before Kodi only when a valid network connection has been established. You basically need to extend the wait-for-network logic to include wireguard.

You're over-thinking the problem. Trying to write the .img to disk again is only going to cause problems because the .img format we use for releases is designed only for overwriting an entire disk. Make a one-time manual install of the partitions and filesystems, and then 'update' to newer versions as required. An update replaces the entire embedded portion of the OS (via KERNEL/SYSTEM) and if you need to wipe the Kodi config all you need to do is stop Kodi and rename /storage/.kodi to /storage/.kodi-old and reboot. On restart you have a completely clean Kodi config. Config items also exist in /storage/.config or /storage/.cache, but it's unlikely that you need to touch anything there.

I downloaded the files from that GitHub repo:

- Centre starts with FL, FR, but then plays FC.

- Quad plays FL, seems to hiccup slightly with FR, then plays RL and RR.

- Stereo plays fine.

- Surround50/50/61/71 all play fine on main channels, there's a quiet moment which I assume is LFE.

I'm using an LE13 nightly image: https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.2.tar

I have fuzzy recall that the setting is fixed/working in the LE13 nightlies, so perhaps put one on a spare SD card and see (first).

There is no way to configure networking from the SD card.

This will be full of prior-art on the topic https://github.com/zach-morris/plugin.program.iagl

It would be more productive to have a simple game library in Kodi that stores a reference to the ROM and preferred emulator.

WireGuard uses symetric keys for encryption but other elements of the protocol like handshaking and key-rotation that are essential for perfect-forward secrecy are time-based: thus the host needs to have correct time before starting, and on most LE devices correct time is obtained via NTP, so removing the time-sync.target dependency would be wrong.

If "when my wifi connection changes" means you have a poor wifi signal resulting in disconnects or failure to connect? the correct solution is always going to be fixing the poor signal.

If Android is installed on eMMC you need to perform recovery boot with the AMLGX "box" image so s905_autoscript or boot.scr can be found in the boot partition. The vendor u-boot looks for these files and loads them; and they reconfigure u-boot to find/boot the LE kernel and device-tree files first (if present) else continue to Android. Once you've booted into LE this way you can either erase/zero emmc using emmctool so the device runs u-boot from SD, or you can download the AMLGX "bananapi-m5.img.gz" image file to /storage and write the image to emmc (again using emmctool). Then the device is booting upstream u-boot from eMMC, but this will look for the .conf on SD before eMMC to make testing from SD easier, else run the image from eMMC which is faster.

On ARM SoC devices that support multiple output planes and where the GPU (2D/3D) is separate from DRM (rendering/compositing) the active planes are processed individually and then composited for HDMI output. There is normally a dedicated OSD plane, and on Amlogic hardware (at least the older generations that LE supports) the OSD plane is limited to 1080p resolution while video planes can handle 4K. The Amlogic vendor kernel does some internal hardware juju to scale the 1080p OSD plane to 4K at a later point in the display pipeline but the visual results of that forced scaling (scaling is always a lossy process) often result in visual artefacts and the output can be visually better when you leave the OSD plane at its native 1080p. I have zero code knowledge of what CE are doing but it sounds like they implemented some settings to fiddle with the kernel and stop the OSD scaling from happening. Other ARM SoC types, e.g. RPi, Rockchip, support 4K on all planes which must be better, right?

The problem is that rendering the Kodi interface always requires scaling of 2D/3D elements (can be accelerated on the GPU) to be combined with bitmap elements; artwork in the skin, artwork from thumbs and scraping (cannot be accelerated, so must be scaled on-the-fly, on the CPU). And as most (all?) Kodi skins are currently designed for 720p or 1080p output, running the 'desktop' at 4K means most of the time you must scale a bunch of things from 720p/1080p to 4K and this has a significant compute impact on the HTPC device. Even if you have "4K native" skins, thumbs and artwork are still scaled, and still generate compute load.

The TV also has its own scaling capabilities for handling SD/HD signals. The TV's capabilities are normally visually better, due to having fancier scaling algorithms, and scaling on the TV has zero compute impact on the HTPC. This means most of the time and even on more compute-capable x86_64 hardware; you have a better overall Kodi experience (fewer visual artifacts from scaling and snappier navigation) when you leave the Kodi GUI at 1080p, not 4K, and only switch to 4K output when playing video. Some users are obsessed with 4K settings though

Quote from kardano

I read that unfortunately the Rasp4 does not have hardware support for H265, which the Rasp5 does

RPi4 supports H264 decode to 1080p, and both RPi4 and RPi5 support H265 decode to 4K60. RPi4 and RPi5 software decode other formats (AV1, VP9, etc.). RPi4 should handle anything else to 1080p whereas RPi5 generally has enough grunt to handle up to 4K30.

RPi5 is faster than RPi4 but since you already have an RPi4 you might as experiment before investing more in upgrades. Amazon shows lots of inexpensive BT or 'USB air mouse' wireless remote options. Or a USB flirc receiver allows you to reuse an existing IR remote that you might have? - RPi4 also supports HDMI-CEC which lots of people seem to use.

popcornmix any ideas?

Done

Stop being a drama queen and exercise some patience. We know IA changes can be disruptive but we are dependent on upstream IA developers figuring out the issue and then merging fixes to their codebase - and we've merged changes to LE within an hour of those fixes being published. The project runs on people working for $free in their spare time, alegedly for fun. You might want to recalibrate your expectations.

I have never booted NOOBS/PINN, but we create tar files for them (still) so see if this works:

https://releases.libreelec.tv/LibreELEC-RPi5.aarch64-12.0.2-noobs.tar

Updates for LE12/LE13 have been merged and should appear in the repo over the next 24h.

There's nothing printed on the board that returns anything on Google, the spec info is too generic, and the manufacturer page contains no details. Dump/share the Android system/boot log and we can probably see what SoC/chipset is inside.

This will be somewhat hard to guess at .. but here's some comments and thoughts:

I'll make an educated guess that you can't SSH to the RPi as the college has implemented guest isolation on the WiFi network. It's a pretty standard restriction in "public" networks to prevent a device from interacting with anything except the gateway. It stops the computer science students from hacking everything (school networks are pretty hostile environments).

RPi boards have no RTC chip so date/time defaults to the libc release date until the network is up and connman makes a successful NTP request to the default pool.0.ntp.org servers (there is normally no need to configure any). TLS certs can be invalidated if time is wrong because e.g. the current date/time is seen to be in the past and the valid-from date for the cert is seen to be in the future so although you have IP connectivity the TLS connection is (correctly) rejected.

So there is probably an issue with NTP. If something blocks external access to pool.0.ntp.org or DHCP does not provide an NTP server (or worst, provides an invalid one) the clock is wrong and services using TLS certs (like repos) may not work. The workaround is to SSH to the device over Ethernet (direct cable) and set the clock to current time. You can also try configuring a local NTP server. If the college doesn't publish anything about their in-network NTP servers, try configuring the IP of the gateway as most will routers will respond to an NTP request.

Another possibility is you need to 'authenticate' to access the Internet? - perhaps the college has a captive portal where you need to enter credentials or click 'go online' to proceed (like a Hotel, Airpot, Coffee Shop). If yes, the two suggestions are:

a) Share the WiFi of a laptop over Ethernet and then connect the RPi to the laptop via Ethernet.

b) Share the WiFi of the RPi over Ethernet and then connect a laptop via Ethernet. This cannot be configured in the GUI, but can be done using connmanctl over SSH; so SSH into the RPi over a directly connected Ethernet cable and then use connmanctl to enable 'tethering' over Ethernet. This will allow you to use a browser on the Laptop to visit the captive portal and complete whatever auth challenge is required.

There's probably other things .. that's just what comes to mind.

Quote from kardano

Hi chewitt, i want to buy a TVBOX with an Amlogic chipset for a good 4K vision: can you recommend me a good device?

In short, no. The 'best' or more accurately 'least worst' supported devices are still S905X/D from the 2015/16 era; I wouldn't really use the word 'good' in the same sentence as Amlogic. Newer hardware has zero support so you're forced to deal with the vendor kernel (we choose not to go there) and their recent technical direction is quite hostile to open-source. I see them as a dead-end for Kodi support on Linux (even with vendor kernels) in the long-term.

The device I use daily and the only one I'll recommend to anyone at the moment is an RPi5.