Posts by chewitt

The WiFi (and BT) devices can be disabled in software through a device-tree overlay. This results in the relevant module not being powered-up, so you cannot gain any power saving in hardware by desoldering the chip. And in software the device simply doesn't exist so you avoid the minimal complexity that might exist.

The board should run fine without the chip if you really really really want to desolder it, but when you break the board due to lack of soldering skills; expect zero sympathy in this forum.

Amlogic are actively upstreaming support for their "newer" chips (since SM1) but their developers are inexperienced at upstreaming to the mainline kernel and indoctrinated on their BSP codebase which "works, but don't ask how" so the initial state of all patches is poor and it takes many slow iterations to raise them to a mergeable standard. In the last week they started to upstream hardware decode support (to supersede the long-stalled upstream 'staging' driver effort) but this is going to be a very long slog.

So I'm confident S905X5M will be supported, but don't ask me which year this will happen in, and please least limit yourself to asking for an update only every six months. And don't be offended when the answer is copy/pasted from the previous question

RPi5 (my family daily driver) is a considerable performance bump over the RPi4. Rockchip RK3588 does not support VP9 hardware decode yet but like RPi5 has a ton of CPU. I would expect it and RK3576 to be nice boards in the mid-term future (long before the newer Amlogic stuff matures). There are lots of inexpensive Intel x86_64 devices these days too.

There's no mention of wlan2 this time. I can only see eth0, wlan0 and wlan1 in the log. NB: If you add dtoverlay=disable-wifi to config.txt it will disable the onboard Broadcom WiFi chip.

Tvheadend has a GitHub repo that accepts bug/issue reports. It also accepts pull-requests. I'm not the Tvheadend GitHub repo.

Share the URL generrated by journaltctl | paste on the 12.2 box after a clean boot please.

As the forum those patches are hosted on requires me to register just to view them, I have no idea whether they are simple nip-tuck patches or something more invasive. Both Tvheadend and Videolan have online repos that accept pull requests, so if the patches are needed, get them submitted -> reviewed -> merged.

Technical Debt 101: If fegol cannot be bothered to upstream patches (authored three years ago) I'm not picking them into the LE codebase, because we will never be able to drop them in future Tvheadend and libdvbcsa package updates.

Either link to the actual patch so we know what you're talking about, or don't be suprised when nothing changes.

Quote from crazyturk

Can you add the ICAM patch to future versions of Tvheadend43?

What patch?

Quote from emveepee

Would it be possible to build ffmpeg with libx264 and libx265 support or are they still too slow?

The ffmpegx add-on provides an ffmpeg binary wth h264 support (not sure about h265). Hardware encoding is still some way off as the kernel is still missing a defined uAPI for V4L2 encoding so there's a choreographed dance between kernel, specs, and userspace apps like gstreamer and ffmpeg to pull off.

Quote from mf_fantail

dmesg showed that the firmware overlay was processed, but the iwlwifi driver was not added.

The RPi5 image doesn't contain iwlwifi drivers or firmware.

This image (LE13) has the driver enabled: https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz

I'd like to know the specific firmware files required for that card, as the iwlwifi folder in upstream linux-firmware contains a ton of files and I only want to pick the subset needed. Please experiment and report back.

Google how to use fdtput and disable the SDIO node for the WiFi device in device-tree. Or blacklist the kernel driver. Or use rfkill.

Have a look here: https://github.com/jefflessard/tm…eedback/devices

If you know the VFD config that worked on CE there should be a matching dtso file. Amlogic u-boot doesn't support overlays so you cannot load/use the dtso overlays directly, but you should be able to look at the content there and see how I've implemented the same changes in board dts files in my kernel branch.

The device-tree content for tm16xx has changed format a bit due to kernel maintainer feedback so the dts files in my 6.17 repo will work with the driver in LE13/master but not the driver in the LE12.2 image.

Some platforms, e.g. SNES, have about 10x possible emulators so the workflow is oriented towards opening the game ROM/file and then selecting the emulator you want to run it with, not running an emulator and then selecting a game.

Please stop creating new threads with the same question!

LE does not have package management. It does have Docker. Docker runs containers, which provide apps to the OS. You can install containers that provide the apps you are looking for. NB: VLC server is not compatible with V4L2/GBM graphics.

Quote from martin.kralicek

Now I am going to try CEC over HDMI

HDMI-CEC is rarely supported on x86_64 hardware so this likely won't work.

There are changes to iptables/nftables in recent kernels and I probably need to spend more time on the issue; which won't happen that quickly as I'm travelling for most of the next week.

The trac ticket is referring to https://code.ffmpeg.org/FFmpeg/FFmpeg/…ac5c69aa1cffffb and a few follow-up commits. This was merged for ffmpeg 8.0 so it will not be in current LE images which use 7.1; we are waiting on an update of v4l2_request support patches for ffmpeg 8.0 to be completed, and then we will bump to 8.0. I am hoping to see patches submitted this week, but the contributor responsible has a history of optimism on dates, so no promises