Posts by chewitt

The hardware decoder is reporting missing information in the media; which normally indicates a media problem and not a decoder problem. FWIW, i'm running my own RPi5 development image (LE13 not LE12) with a broadly similar setup and I don't see the same errors with a wide selection of test, broadcast, and self-ripped 10-bit HEVC media.

Feel free to test https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz - make a backup of /storage/.kodi first as Kodi does not support downgrades. There are also some binary add-ons missing in the repo that image uses right now, but that will resolve itself over the next 24h or so as they are built and published.

If you remove the eMMC module (to ensure it's not used) and create a new SD card from a current image, will that boot?

How have you determined that it refuses to start? .. do you have a UART cable connected allowing you to see that output stops at a specific point (if so, which point, share logs) or simply you see nothing on the screen? .. which usually means the OS is running but something stopped Kodi from starting (meaning you can SSH in and share logs).

Put Kodi in debug mode and then run "pastekodi" to share the Kodi and system log after OOM kills Kodi again. I've also seen some OOM events in recent days; albeit on an RPi5 and RK3588 device that are running my own LE13 development images which have little in-common with the LE12.2 codebase so no guarantee it's the same issue. NB: the logs aren't going to reveal the source of the problem, but will contain info on wider Kodi configuration which might be helpful.

Quote from GloriousShield3576

ailed to start display.service. If that is of any importance. I didn't find it in the log.

This is harmless, there is no VFD display found. You can stop with systemctl disabled display && systemctl mask display

There is no mirror redirection for add-ons, and these days we don't block any IP/CIDR ranges either, so if the device cannot connect to the repo the issue is likely something on your end.

FWIW, I have no issues downloading add-ons on an RPi5 here, and RPi4/5 use the ARMv8 add-on repo so that's correct.

Have you tried force-refreshing the repo in Kodi?

In the absence of any technical detail (debug logs and such) .. no idea what the issue is

In crypto things IKE is normally an acronym for "Initial Key Exchange" but no idea if this is correct here.

NB: If Yemen is anything like the UAE, you need to visit the local computer souq and find the guy that specialises in satellite things, and they will know how to set-up the right software/hardware to make things work (insh'allah). In this forum you'll only find people that understand how to make things work in the EU and maybe US, but not Middle-East countries.

Quote from rawnar

I can clear the emmc using the following command LibreELEC:/ # emmctool zero. After which I can boot using the "wetek-play2" image installed on a second SD-Card using the LibreElec USB-SD creator. Right?

Correct.

I'll fix the missing 'b' for backup in the next update to Amlogic or Rockchip that I push to master.

There is no known Kodi SMB client bug in K22/LE13 images. Have you bothered to experiment with the protocol version as asked?

You cannot boot the "wetek-play2" image from SD card without first erasing emmc (use emmctool from the box image) because if vendor u-boot exists on emmc the box always boots it and not mainline u-boot from the SD card. The boot partition on the SD card contains only extlinux.conf for mainline u-boot and this is not seen/understood by vendor u-boot; hence it cannot find legacy boot files. You can of course copy s905_autoscript etc. over from the box image but this replicates booting the box image from vendor u-boot which doesn't proove the issue with mainline u-boot is resolved.

So, erase emmc to force mainline boot from SD card. If the noise issue is resolved then it should boot. If it is not resolved, it will drop to the u-boot console where you can type 'boot' to continue booting. If you want/need to revert back to vendor u-boot I have a raw disk (dd) backup that can be downloaded and copied to /storage on the SD card and written back using emmctool again.

No idea

K22 contains some minor changes to the SMB client:

* Defaults to SMBv2 and large MTU support (not plain SMBv2)

* Defaults to 128k chunk size (and size is configurable)

The defaults were chosen by Kodi devs to work for the majority of people but perhaps your old router needs something different. Go experiment with options and see if that results in working connections again. I'd start with the minimum protocol.

It would be better to post on https://github.com/ampache/ampache/discussions

I might be missing something, but what has this got to do with LibreELEC?

garbear any ideas?

Anything on the UART output? (this is why it's kind of needed for these tests)

When you say things are very-clear on the Free Guy movie; what is the frequency that the dropouts occur? .. because watching that movie I hear only a handful of audio glitches in the 2-hour movie. Again, from the way people have been moaning I'm expecting to hear something every few minutes to create a constant annoyance but that's not what I'm experiencing. To be clear, I do hear some glitches, but I want to ensure I have the same experience as others.