It's working here on an iPhone 14 (17.6.1) using Librespot and normal Airplay streaming. I'm technically using an LE13 image and an RPi5, but the Kodi version is from before the bump to Kodi piers (i.e., the same Kodi version as LE12 images), the Liprespot add-ons are essentially identical, and RPi4 vs RPi5 makes no functional difference. NB: Airplay streaming generally works better, there's less lag on playback, but I assume that's not an option if using an Android phone.
Posts by chewitt
-
-
Nothing in the logs (as expected). Since Intel drivers are involved (and them having such a wonderful reputation) take a backup and bump to the latest LE13 nightly which is now running Linux 6.10 (so newer Intel drivers). I'm grabbing at straws a little, but there's logic to the request.
-
How does the Android running Chromecast 4k do compare to LE on RPI4B for video hardware acceleration or graphical UI?
Does Android use OpenGL or Vulkan for this?
The Chromecast has an Amlogic S905Y3 chip with Mali G31 GPU inside and supports OpenGLES. It's a faster chip than the Broadcom SoC in the RPi4, and the OS runs from internal eMMC storage, but Android has a much greater general OS overhead so I usually find the Kodi GUI runs "about the same" on most Android devices with my (large) media collection as it does on an RPi4B's inferior but less loaded hardware.
Hardware Video Acceleration is something different. RPi4B supports only H264 (to 1080p) and HEVC (to 4K) whereas the Chromecast supports a much wider range of codecs. That said, most of the extra codecs Chromecast supports are legacy ones and the RPi4B can software decode the legacy media using them. The main real-world difference will be VP9 media support.
Note that RPi5 significantly outperforms RPi4.
-
Share a full debug log file .. it will contain more info on your setup.
-
The bug I am referring to in that thread is this one https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10199
I've no idea what the issue you're seeing is, but I'd ask that you try updating to a current Generic (non-Legacy) LE12 nightly to see if any of the changes pending for 12.0.1 make a difference?
-
Only major pain in the butt I really encountered was Windows' habit of assuming it's the only OS on the disk
Yup, Windows does that. What to do
-
The GPLv2 Linux kenel is considered to be pure code from a license perspective, so loading an external vendor module that often has no license or some proprietary license "taints" the kernel's purity. In short, the messages are harmless.
-
No RPi board has hardware support for VP9 media and RPi3 doesn't have the CPU grunt for software decoding. You need to use H264 content (which can be decoded) or use different hardware. RPi4 can handle 1080p and RPi5 has the oomph to handle most 4K30 VP9 media (but not 4K60).
Updating to LE12 won't solve anything.
-
Code
video=HDMI-A-1:1280x720M@60Older "HD Ready" TVs often support 1080i resolutions not 1080p so you might need to force 720p output by adding that ^ to the boot params in cmdline.txt (on the same line). Also try different cables on different TV ports.
-
why isn't Libreelec/connman using the Proxy-config from Kodi for these checks?
Proxying in Linux is always application specific so Kodi proxy configuration is for Kodi and is not shared to other applications. You can also set a proxy in ConnMan (per connection) but I have a hunch the initial requests for ipv4/ipv6.connman.org are intentionally not routed to a configured proxy as those checks are performed before the network is declared up (and thus the connection that proxy config is associated with is not yet established).
-
I think nightlies need me to finish working on a Linux 6.10 kernel bump and send a pull-request, but that might take a while as work and life have a higher priority at the moment. Hopefully before the end of August, insh'allah.
-
LE has no use-case for video encoding so it's not something I can comment upon. Video decoding is generally supported.
-
Code
2024-07-29 15:26:39 up 10 min 538352 2024-07-29 15:27:39 up 11 min 543008 2024-07-29 15:28:39 up 12 min 542848 2024-07-29 15:29:39 up 13 min 544544 ... 2024-08-03 11:15:11 up 4 days 803584 2024-08-03 11:16:11 up 4 days 799680 2024-08-03 11:17:11 up 4 days 799888 2024-08-03 11:18:11 up 4 days 810112Defnitely an increase in RAM consumption over time, but figuring out what is beyond my Linux skillset.
-
The debug log doesn't show anything being played, so not much use
-
I believe you are using rockchip BSP.
LE runs upstream mainline kernels only (inevitably with some patches, but we try to limit that). LE 11.x uses Linux 6.1, LE 12.x uses Linux 6.6 and LE13 (master/dev) currently usues 6.6, 6.9 or 6.10 depending on the SoC platform. All kernel and ffmpeg sources are in the buildsystem.
BSP kernels are universally horrible and need to die in fire
-
Diff
--- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1996,6 +1996,7 @@ static const struct snd_pci_quirk force_connect_list[] = { SND_PCI_QUIRK(0x1043, 0x86ae, "ASUS", 1), /* Z170 PRO */ SND_PCI_QUIRK(0x1043, 0x86c7, "ASUS", 1), /* Z170M PLUS */ SND_PCI_QUIRK(0x1462, 0xec94, "MS-7C94", 1), + SND_PCI_QUIRK(0x8086, 0x06c8, "HP", 1), /* Elite Mini 800 G6 */ SND_PCI_QUIRK(0x8086, 0x2060, "Intel NUC5CPYB", 1), SND_PCI_QUIRK(0x8086, 0x2081, "Intel NUC 10", 1), {}If anyone can build a test image (I'm not able to build things where I am) .. that ^ kernel patch should do it?
If you can confirm yes, I'll upstream the patch to the kernel.
-
Code
video=HDMI-A-1:1920x1080M@60 video=HDMI-A-1:1280x720M@60Add one of these ^ to boot params in cmdline.txt in the root folder of the SD card (on the same line). If the TV can do 1080p use that one. If it's an older "HD Ready" set use the 720p line. Any better?
-
The next step is to figure out the kernel patch required so that you (and anyone else that ever tries to run some Linux distro on the same hardware) doesn't require hours of Googling and workarounds.
