Posts by chewitt

It's useful to have a large collection of experimental nightly images on the test server so less technical users can self-triage issues by stepping backwards in time and figuring out when a problem first occurs. Our goal is to store the largest number of files that we can, and that's not going to change, even if it slows the updater a little.

In the absence of a debug log .. we have no idea what the issue is

It probably has something to-do with the media height being outside match parameters in code. The first (working) media is normal 2160p while the second (non-working) is 1592p. I'd expect that if you re-encode the file to a 2160p resolution (adding black bars) the resolution will match whitelist entries and play correctly. I'm not aware of any other remedy..

You cannot store things directly in /var/lib/alsa because /var resides inside a read-only squashfs file that's decompressed on boot to create a non-persistent virtual filesystem.

You can put symlinks inside the read-only squashfs file that relocate the directory to locations like /storage/.cache/alsa which can persist data on a read-write volume. You can have systemd create directories on first-boot as needed; see packages/network/bluez/tmpfiles.d/z_05_bluez.conf for an example.

The boot issue should be resolved in LE12 images; e.g. the C2 image here: https://chewitt.libreelec.tv/testing/

CONFIG_USB_OTG=y is set in the kernel defconfig so it's built-in not a loadable module but dr_mode is set to "host" not "otg" in the upstream C2 device-tree so you'll need to change that; either with a tweaked and recompiled device-tree or with fdtput commands executed from userspace at boot-time.

If it's possible to use a compile time option to change/specify the state location we can modify the relevant alsa package.mk to set that to a /run/alsa/ or /storage/.cache/alsa location at compile time. If there's none in current code we probably need to find where it's defined in code and patch the location (or patch making it configurable and send the patch upstream).

Quote from dpapavas

My only concern is with testing, as LE runs on a lot of disparate setups and I can only test it on one of those.

It would be good to have something submitted that can be smoke-tested and critiqued by staff first, then after LE12 ships (so early in the LE13 cycle) we can merge the change to nightlies. If there are minor problems we work on fixing them, and if there are major ones we can revert the changes and rethink.

In short, as long as you're patient and understanding (this is a large change, we'll be cautious about it) .. all will be fine

On the RPi4:

touch /storage/.update/.nocompat
cd /storage/.update
wget https://releases.libreelec.tv/LibreELEC-RPi5.arm-11.0.6.img.gz
reboot

On reboot the RPi4 updates to the RPi5 image, and on completion and second reboot it attempts to boot the RPi5 image. This will either fail or half-work so it's best to pull power on the RPi4 as the second reboot starts. Now transfer the SD card to the RPi5 and things should work.

Or .. do a clean install and manual copy/paste migration of any essential content from the RPi4. The boards use different images so unlike previous RPi2 > RPi3 migrations you cannot simply swap the card.

In 99% of "stuck on boot screen" reports the OS/system is running and can be accessed via SSH. In the case of a VM that won't be simple as the SSH daemon is not enabled by default and you'd need to mount the VM disk from another Linux VM to access the boot partition and edit syslinux.cfg to force it on by adding "ssh" to kernel boot params. However the Samba server should be running so if you find/access the "Logfiles" share the OS will generate a zip file with logs. If you share that file here we can see the boot log and that might give some clues on what's not working. It's most likely an issue with graphics drivers, as no GPU = no GBM surface for Kodi to render a GUI onto, but we'd need to see error messages to understand the problem.

NB: The OVA exists solely to support internal development/testing and sometimes gets broken and isn't updated/fixed until the next time someone on staff needs it to work again. In short, it's not something we formally support or spend much time on.

LE does not support dual-boot and our installer will nuke anything else on the same target disk. Mint installer will be more flexible and should allow install into a specific partition, but if LE was installed first there isn't a spare partition so you may be nuking bits of LE when installing Mint, and Mint probably installs its own bootloader (overwriting ours) and either doesn't support making pretty menus that include existing other OS on the disk or it does a bad job of that.

The LE installer simply creates two partitions; one for boot files (SYSTEM/KERNEL and syslinux.conf) and one for a persistent storage area (/storage) and it installs the syslinux bootloader to the root of the disk. We are not dependent on syslinux; any bootloader will be fine, so it will be best to install Mint with a partition scheme that allows for LE being manually installed (copy boot files over) and with a manually created entry in the Mint-installed bootloader (they probably use grub).

TL/DR: there's a reason why we don't support or provide support on dual/mult-boot arrangements. Good luck

Look for a "portable" win7 or win10 image .. there are lots around, and HDMI/LSPCON firmware updates do solve a lot of problems

chewitt@toolbox:~/LibreELEC.rpi$ git grep HID_PLAYSTATION
...
projects/RPi/devices/RPi/linux/linux.arm.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi2/linux/linux.arm.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi4/linux/linux.aarch64.conf:CONFIG_HID_PLAYSTATION=y
projects/RPi/devices/RPi5/linux/linux.aarch64.conf:CONFIG_HID_PLAYSTATION=y

The driver is enabled in our kernel configs ^ and I confirm it works with a PS4 controller via Bluetooth (code for the PS4 controller was ported from CONFIG_HID_SONY after the hid-playstation driver came into existence).

Is anything reported in dmesg? (share a logfile)

Quote from dpapavas

We'll hopefully know in a day or two, or sooner if I'm not lucky.

Fingers crossed .. keep me posted

I'll add the firmware to official LE12 images in the next set of changes I push (which is overdue). You can use the ones I have in my test share until then. Thanks for reporting back

I have a modern TV which supports 1080p @ 60/59.94/50/30/29.97/25/24/23.976 modes, but only 720p @ 50/60 Hz. As 99.999% of the movies in my collection are 23.976fps the playback experience will be better with 720p upscaled to 1080p where the fps/Hz rates will result in an exact match.

However, if all the media is e.g. downloaded BBC iPlayer content at 720p@25/50 then I would also have an exact match with the 720p modes on the TV; and then I would need to compare upscaling done by the TV to upscaling done by Kodi .. and this is always going to be subjective to what I think it better, and how good my TV is at the task, i.e. my TV might be better than your TV (or vice versa).

TL/DR: Only you can answer the question. Go test

Merged

I'd test with/without the clm_blob as those are 100% implementation-specific and can cause issues on the wrong board; and it would not surprise me if Radxa blindly copied the files in their repo from somewhere like Armbian (look mum it works.. job done). I'm also unsure that brcmfmac supports the same naming overrides for clm_blob as the bin/txt files? (something to test).

I'll also comment that "newer is not necessarily better" as Broadcom (like all SoC/chip vendors) fork code for each new customer project; creating the opportunity for all-new and exciting bugs that don't exist on previous/older forks previously created for a different customer. It's all under "version control" but the process isn't what you wrongly assume it to be

NB: This has been lurking on our repo for a while https://github.com/LibreELEC/brcmfmac_sdio-firmware/pull/30

I have fuzzy memory of testing the files on an Amlogic S912 board when it was PR'd and it broke WiFi so I didn't merge; but I should probably go back and test again. The problem with these files is - they are all supposed to be board-specific which makes packaging for a generic distro a "choose your compromise" game.