Posts by chewitt

PrefferedTechnologies should determine which active technology has priority for the default route. If both Ethernet and WiFi have access to the internet then ethernet,wifi should result in the best connection to both internet and NAS. If only WiFi provides access to the internet wifi,ethernet will be required to ensure the default route shifts to wlan0 when the USB WiFi adapter is connected and active. If for some reason traffic to the NAS is routing over WiFi (or perhaps both) interfaces you might need to configure a static route that instructs traffic to the IP of the NAS to route over eth0. There is no way to configure that from ConnMan, but it's easily done using a system.d service, e.g. something like this (untested):

RPi5:~ # cat .config/system.d/static-route.service
[Unit]
Description=Static Route Service
After=network-online.target nss-lookup.target time-sync.target
Wants=network-online.target nss-lookup.target time-sync.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ip route add 192.168.2.100/32 via 192.168.2.1 dev eth0

[Install]
WantedBy=multi-user.target

Create the file then systemctl enable /storage/.config/system.d/static-route.service and systemctl start static-route and the connection will be reapplied on each boot.

No monitor/TV = no EDID data from HDMI = no alsa devices detected in Kodi = ??? but possibly something internal to Kodi depends on an audio sink being active (and in LE this defaults to alsa) for AirPlay to work. There's probably a logic bug in Kodi there, but the workaround is to run "getedid create" over SSH with the monitor attached. This captures the EDID data from the monitor and forces the kernel (and thus Kodi) to always see that monitor as connected.

I wouldn't expect it to cause issues, but it's always a possibility. Perhaps install the multimedia-tools add-on from the LE repo and then use alsamixer to reduce the output level on the master volume controls. I'm wondering if the signal is just over-driven.

Boot the board without an SD card connected. On the bottom of the resulting 'bios' like screen it will show EDID as 'OK' or none. If it shows 'OK' then I can't explain the problem. If it shows 'none' then something is not right in the chain between board and the TV; the EDID data on the HDMI connection contains info on HDMI audio capabilities so no EDID data means no audio in Kodi (hence only the BT audio pulse device shows up). TL/DR; check cables and ports and that everything is seated correctly.

I updated https://chewitt.libreelec.tv/testing/LibreE…-rock-5b.img.gz first before starting some work on an ARMv8 image that might become the future of support. We build too many images that are essentially the same aside for some compile time optimisation that doesn't make a huge different to performance. Consolidating to a single image will save a ton of CI time when building nightlies and releases.

Add video=HDMI-A-1:1920x1080M@60D to kernel boot params in extlinux.conf and see if that helps?

LE creates two partitions to run from: the first (boot) partition is 512MB and with the OS being 160-300MB in size (depending on the hardware-specific image used) that's enough. The second (storage) is more critical and needs to have 2-4GB of space for an install with media stored elsewhere (USB drive, NAS in the network etc.) or more if media is locally stored on the same drive.

So unless there's an actual problem .. "nothing to see here, move along please"

I've noticed occasional audio dropouts during movies, but there are no traces of anything in Kodi or ffmpeg logs and the event is not reproducable, e.g. rewind media and the event does not reoccur at the same point. I have no idea how to reproduce or debug this so it's something I need to flag to upstream devs. I have a hunch (based on similar issues with Amlogic hardware) that this is related to unstable clocks, but I have no way to prove that and I have low expectations of an easy find or fix.

I've not experimented much with 192KHz audio. If you have some structured test media that you can share, send me a download link; email to chewitt@ our domain or Kodi domain.

I've not seen dropped frames in videos other than some known-bad test media with exotic/problem encodings, but playback is sensitive to using correct modes so I would strongly advise everyone to use adjust-refresh and the general config outlined in this wiki article: https://wiki.libreelec.tv/configuration/4k-hdr

The kernel DRM layer is using HDMI 2.0/2.1 mode timings which are standards and both LE and Armbian are broadly using the same versions of mesa/panfrost, although this is only relevant for rendering the Kodi GUI an has nothing to do with HDMI modes and DRM connector timings. The one possible difference between LE and Armbian is that I have a bunch of in-flight patch series that enable deep-colour and HDMI 2.1 capabilities in the kernel and Armbian probably doesn't. That's all going to be merged upstream at some point though, and it's still the AVR's responsibility to generate its own OSD and overlay this onto the HDMI signal sent to the TV so if it can pass HDMI video/audio but not show its own OSD that sounds like an AVR bug. FWIW, the OSD of my 2018-ish Marantz AVR shows up fine on the rare occasions I display it.

There are lots of in-flight patch series required for the image. All current hardware decode ones are included.

I've no idea why those specific resolutions are duplicated in the selector on your system but there is presumably a difference other than the resolution that results in a different mode being listed. The display order in the GUI should be the same as the "Found resolution" data you can see in a kodi debug log (must be a debug log). You can also compare the output of "modetest" on the CLI to see what's listed there.

NB: There is no separate deinterlace section. If there are 1080@25/29.97/30 modes in the whitelist deselect them. If none of those modes are selected .. don't select them.

AFAIK the images Oleg was building are/were largely the same as official nightlies (other than nightlies now being on newer kernels and other packages). I've not heard of audio issues with current nightlies. Are you using HDMI output or the analogue port?

Quote from myrkle

Is that what you meant by "manually update"?

As nightlies can contain breaking changes we don't publish a 'releases.xml' file so neither manual update from the GUI or auto-update are possible. You need to download the update file to /storage/.update and reboot.

Papaya5595 I've updated the RK3588 images in my test share to include newer iwlwifi firmware.

Quote from myrkle

I assume this is because the build I'm using is an old alpha build and the repository doesn't support older alpha builds.

As a general rule we keep the current and current -1 repo versions for development images online, but we remove older repos to reclaim disk space. The repo version aligned to that image has probably been deleted.

You should be able to run touch /storage/.update/.nocompat and manually 'update' to a current LE13 nightly. The compat check needs to be skipped as the image name changes from ARMv8 to RK3399.

Thanks for confirming. I've submitted https://github.com/LibreELEC/LibreELEC.tv/pull/10859. Once merged support will be in LE13 nightly images and you can remove the /storage/.config overrrides.

Quote from Mayoru

I'm a bit confused.

Most people get confused with Docker and containers so don't sweat it

Containers virtualise an app within a supporting environment. In our case the app binary is 'make' although this is not that clear unless you understand how our buildsystem works.

The docker steps are correct. The info that's probably missing is an instruction to git clone the LE sources first.

Then you need to 'docker build' the container by 'pulling' from a docker source. This is a local Dockerfile and not a URL or a pre-built container from the online docker 'hub' repo. From a cloned LibreELEC.tv source folder the source files are in tools/docker/

Then you need to 'docker run' the container, with the run command providing instructions to the docker runtime on directories to map, and buildsystem variables (PROJECT=X, DEVICE=Y, ARCH=Z, etc.) that are passed to 'make' to define what image to create.

It might be easier to run an Ubuntu server LTS release VM under proxmox and SSH into that environment to install dependencies, clone sources, and build using the CLI commands that you can see in the normal build instructions. The main reason we support Docker building is for our own CI use-cases building nightlies etc. .. not because it's a better/easier option.

Quote from nick.ross

Why don't you just publish a list of common channels that work?

If an add-on is published in the Kodi repo, the Kodi ecosystem assumes it works and is maintained. If it doesn't work, that's an issue to be reported to the add-on maintainer(s) via their add-on support thread in the Kodi forum.

Quote from nick.ross

My back story is irrelevant but yours somehow transcends all criticism. how relevant is it that you as a moderator have a Pi that works to a new user whose doesn't?

My backstory and role as a moderator doesn't have any relevance to your inability to provide basic information. Six paragraphs of wordage in your last post enlightened us to one piece of useful info: You have an RPi5. The rest of your posts are just complaining about add-ons not working without even bothering to mention the name of one of them. I've suggested twice that you provide us with logs and more specific info. The ball is firmly in your hands to provide facts to help the people who are (or in my case, were) trying to help you.

Good luck

I have a bunch of add-ons installed (on an RPi5) and everything works. Add-ons like YouTube need personal API keys to work. Add-ons that access legal streaming services increasingly need some kind of working credentials, and some add-ons access services that are geolocked to specific countries.

Again, without logs or knowing any specifics of what you are trying to install and use (preferrably with less irrelevant backstory) we cannot provide any specific advise.

Yes, same image name (but image content is updated). Just drop into /storage/.update and reboot.

Most add-ons are not authored by LE staff and 'legal' media content/streaming ones are generally supported via threads in the Kodi forum where the add-on creators hang out. If you want us to help, you'll need to divulge clues like the type of hardware used, image version, specific add-on details (no idea what "esa" is) and likely provide some logs (read the wiki).

Otherwise it's a bit like saying "my car doesn't work, it's a red one, what's wrong?" ..