Is there a minimum USB stick size in "Run" mode to play a 25 GB .m2ts file without problems?
26GB would do it, but since those don't exist the logical size would be 32GB
What is the "nightly" version?
LE13 development image: https://test.libreelec.tv/13.0/Generic/Generic/ (scroll to the bottom for latest)
Kodi has standard/advanced/expert settings modes and standard hides some of the PT audio options. Are you using the higher ones? .. have you enabled True-HD pass-through?
If yes to both I'd ask you to update to a current LE13 nightly and test again (and share a log using the pastebin function in the LE settings add-on) as this eliminates everything that got fixed since LE12.x; even if we find an issue on 12.x now the fix will be in 13.
Ahh, I'm not interested to add support for boards that nobody is using so it's not in the official list right now. The board appears to have upstream kernel and u-boot support so adding it is a trivial task. How it then works is a different set of questions; Rockchip is still maturing but moving in the right direction.
Are you talking about the OS configuration wizard in the Kodi GUI (system name, wifi, services, etc.) or the installer wizard used for selecting a target disk to install the OS to?
If the former, this is good and the box is booting okay and you have a clean Kodi environment (as /storage/.kodi was renamed out of the way). This was intentional to ensure there is no conflicts with add-ons compiled for Xorg not GBM. You can restore the previous config by stopping Kodi and swapping the folders around again; or if there are any issues, by stopping Kodi and moving specific bits of config back again (add-on settings, sources, passwords, etc.). Binary add-ons like screensavers/visualisers compiled for the Generic Legacy (Xorg) image are not compatible with the Generic (GBM) image so I would normally suggest the partial restore option, or swap folders back but deliberately nuke /storage/.kodi/addons/* then reinstall add-ons.
If the latter, no idea what's going on..
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?
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.
