Posts by chewitt

The behaviour in suspend is largely determined in u-boot firmware.. but that's all I know. It's not my area of expertise.

ffmpeg[0x105b0020]:   Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, progressive), 3840x1606 [SAR 1:1 DAR 1920:803], 23.98 fps, 23.98 tbr, 1k tbn (default)

The only unusual thing that I see is the resolution (3840x1606) which has an unusual height (aspect ratio) although later in the log Kodi is selecting the [email protected] mode in the whitelist. I'm wondering if the dimensions fall outside expected limits elsewhere in the video pipeline, e.g. sometimes drivers have hardcoded expectations on things being generally 16:9 or 4:3 ish.

First thing to do in any case is update to a current LE13 nightly to eliminate everything fixed since 12/12.2. Any difference?

Quote from swever

LE is indicating that its only detecting around 4GB of RAM in the System Information

Some of the Rockchip kernel drivers assume 32-bit memory regions (under 4GB) and behave badly when the OS has more, so we currently limit what the kernel can access via mem=3838M in kernel boot params, https://github.com/LibreELEC/Libr…56X/options#L31 to workaround the problems. You can remove the cap and might briefly see 8GB reported, but then it will lock up. LE rarely uses more than 1GB in normal Kodi use so the cap shouldn't be a problem.

This has been resolved. I've forked Milhouse's repo to the Kodi GitHub org where it can be maintained semi-officially.

I've never done quantitive testing to find the go/no-go bitrate values for an RPi5 so I can't really comment in that level of detaill. I can only state that most lower refresh-rate 4K/VP9 media that I've played streamed fine, and most higher refresh-rate 4K/VP9 media stuttered like hell because the CPU couldn't handle the workload. Standards like QHD/FHD that solely define the number of pixels in a frame are only one of many variables that impact the stream bitrate (bit-depth and colorspace are also important) so trying to simplify to "FHD works, QHD does not" is not possible. If you encode media with the right settings 4K60 VP9 will play. You'll need to compromise the quality of the image to achieve it, but it will play. You can equally generate 1080@25 media with encoding features that challenge the CPU and tie it in knots. The devil is in the details. NB: the YouTube add-on has controls to cap VP9 at 4K@30 and that normally keeps things in the realm of the possible.

Force refresh the repo.

I find "4K" depends on the stream bitrate which normally correlates to the refresh rate. Most 4K@25/30 media in VP9/AV1 plays fine as the CPU has enough grunt to handle software decoding. If the stream is 4K@25/30 with a high bitrate (rare, as YouTube processes all uploaded media so you get a level of bitrate conformity) or if the refresh rate is 4K@50/59.94/60 the stream normally stutters like hell as the CPU simply doesn't have enough grunt to keep up.

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.