Our general policy is not to touch the content of release branches outside of the Kodi version (usually the focus of the bump) unless there are known bugs or security issues solved. LE13 nightlies are stable if you really need the newer version.
Posts by chewitt
-
-
BIOS update? .. See if you can boot an Ubuntu live image off USB reliably. If yes, switch the bootloader on the boot device from syslinux to grub2 (as used by Ubuntu). If there's no difference and no BIOS updates available, there's not much we can do as we didn't boot and run yet.
-
It's not particularly enlightening for me, but it might be more meaningful to a mesa developer
I'm currently building a GBM image based on the LE12 codebase. K22 contains some reworking to GLES shaders. So I'd like to run a test with K21 as it predates those changes and we can eliminate them from suspicion.
-
Wrong. You want to keep the existing K20 table versions (which have the working LE11 database) and delete anything newer so that an upgrade from LE11 to LE12 on a working device triggers DB migration.
-
If Ubuntu will only boot in safe mode, it suggests something is odd with the hardware. The installer should generate a logfile in the root folder of the USB, which might (or might not) contain some errors that shed light on the issue.
-
Looks like something went wrong in the paste upload, as it's only 200 lines long.
-
Run "journalctl | paste" and share the URL
-
Johpin can you share the system log too? .. Kodi dumps the environment debug there not to it's own log.
-
On an RPi5 (and cross-checked on AMLGX, both are GBM) the Kodi debug log shows this sequence:
Code
Display Moreeger_functions GL_EXT_color_buffer_half_float GL_EXT_texture_mirror_clamp_to_edge GL_KHR_parallel_shader_compile GL_EXT_EGL_image_storage GL_MESA_framebuffer_flip_y G L_EXT_depth_clamp GL_EXT_texture_query_lod GL_MESA_sampler_objects GL_EXT_EGL_image_storage_compression GL_EXT_texture_storage_compression GL_MESA_bgra 2025-01-22 10:13:39.738 T:10583 debug <general>: OnLostDevice - notify display change event 2025-01-22 10:13:39.738 T:10583 debug <general>: CDRMUtils::SetMode - found crtc mode: 1920x1080 @ 60 Hz 2025-01-22 10:13:39.738 T:10583 info <general>: GLES: Maximum texture width: 4096 2025-01-22 10:13:39.820 T:10583 debug <general>: EGL Debugging: Error: EGL_BAD_SURFACE Command: eglSwapBuffers Type: EGL_DEBUG_MSG_ERROR_KHR Message: dri2_swap_buffers 2025-01-22 10:13:39.823 T:10583 debug <general>: CDRMAtomic::FlipPage - Execute modeset at next commit 2025-01-22 10:13:39.831 T:10583 debug <general>: CWinSystemGbmGLESContext::PresentRender - Sending display reset to all clients
In the Nouveau (GBM) log the last item is GL_MESA_bgra so I am assuming the CDRMUtils::SetMode and whatever that translates into with the EGL context are the changes that trigger the segfault. I don't understand why we trip and show the EGL_BAD_SURFACE error, but this is normally harmless (shows on all GBM devices).
The crashlog shows:
Code
Display MoreThread 1 (Thread 0x7fd83dee5f40 (LWP 833)): #0 0x00007fd840115a06 in ?? () from /usr/lib/libgallium-24.3.3.so #1 0x00007fd8401575cc in ?? () from /usr/lib/libgallium-24.3.3.so #2 0x00007fd8401578f4 in ?? () from /usr/lib/libgallium-24.3.3.so #3 0x00007fd84015d92e in ?? () from /usr/lib/libgallium-24.3.3.so #4 0x00007fd84007c18c in ?? () from /usr/lib/libgallium-24.3.3.so #5 0x00007fd84007cdf9 in ?? () from /usr/lib/libgallium-24.3.3.so #6 0x00007fd84015da31 in ?? () from /usr/lib/libgallium-24.3.3.so #7 0x00007fd83fa8e3ec in ?? () from /usr/lib/libgallium-24.3.3.so #8 0x00007fd83f9f65cb in dri_flush () from /usr/lib/libgallium-24.3.3.so #9 0x00007fd842322e55 in ?? () from /usr/lib/libEGL.so.1 #10 0x00007fd84231ff13 in ?? () from /usr/lib/libEGL.so.1 #11 0x00007fd842314911 in eglSwapBuffers () from /usr/lib/libEGL.so.1 #12 0x00000000015094b0 in KODI::WINDOWING::GBM::CWinSystemGbmGLESContext::SetFullScreen(bool, RESOLUTION_INFO&, bool) () #13 0x0000000000c4caa8 in CGraphicContext::SetVideoResolutionInternal(RESOLUTION, bool) () #14 0x0000000000e934a0 in CApplication::InitWindow(RESOLUTION) () #15 0x0000000000e9aed6 in CApplication::CreateGUI() () #16 0x0000000000d469bd in XBMC_Run () #17 0x00000000008e6045 in main ()
I'm not an expert in backtraces, but it looks like we are opening a new context and we do something with buffers (which I assume trips EGL_BAD_SURFACE and then we see dri_flush and the segfault:
CodeJan 21 08:23:48.613409 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120 Jan 21 08:23:48.616747 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120 Jan 21 08:23:48.620080 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000120 Jan 21 08:23:48.623435 LibreELEC kernel: nouveau 0000:02:00.0: gr: intr 00100000 [ERROR] nsource 00000002 [DATA_ERROR] nstatus 02000000 [BAD_ARGUMENT] ch 2 [00061000 kodi.bin[833]] subc 7 class 4497 mthd 0208 data 00000140 Jan 21 08:23:48.810100 LibreELEC kernel: kodi.bin[833]: segfault at 0 ip 00007fd840115a06 sp 00007fff2122b1c0 error 6 in libgallium-24.3.3.so[786a06,7fd83f98f000+111f000] likely on CPU 1 (core 1, socket 0) Jan 21 08:23:48.810300 LibreELEC kernel: Code: 00 00 48 8b bf f8 04 00 00 48 89 04 24 8b 82 d8 02 00 00 c7 44 24 08 02 03 00 00 83 c0 01 89 82 d8 02 00 00 89 06 48 8b 47 30 <48> c7 00 6c fd 08 00 8b 16 48 8d 48 0c 48 89 e6 48 89 4f 30 89 50
I'm no expert in mesa debugging, but can you set the following to see if we can get more output:
Codeecho "NOUVEAU_LIBDRM_DEBUG=1" > /storage/.config/kodi.conf echo "NOUVEAU_DEBUG=1" >> /storage/.config/kodi.conf echo "EGL_LOG_LEVEL=debug" >> /storage/.config/kodi.conf reboot
Then pastebin the Kodi crashlog URL as before.
-
Kodi has a single 'Favourites' section that you can store things to. It does not support multiple collections of favourites, if that's what you mean by folders? .. If you want that to change, file a feature request in the Kodi forum, then either contribute the code yourself to implement the feature, or wait very patiently for someone else to do it. The latter might be a long wait.
-
You can install alsamixer via the "Multimedia Tools" addon in the LE report (Program add-ons). It's used from the console though, not from the GUI.
-
For shared DB's to work you either need all devices on the same Kodi version, or you need to accept the DB's for K20 (LE11) and K21 (LE12) are not synchronised and manually keep things up-to-date by marking things watched and scraping new media as needed.
I'd guess you test-updated to LE12 in the past which resulted in one of the devices migrating the K20 SQL DB tables to the K21 DB version. You haven't used K21 since so the data is stale, but it exists so (correctly) no migration takes place, and when you run the RPi4 it sees the K21 DB tables and uses them.
To force DB migration again you need to drop the K21 database tables from the SQL server, see https://kodi.wiki/view/Databases for info on table versions, and then bump one device from K20 to K21 so the latest K20 data is migrated (again).
To investigate the PC's not connecting, put Kodi into debug mode and bump to LE12 then run "pastekodi" and share the URL so we can see the debug log and perhaps spot what the issue is.
-
Have you enabled Advanced or Expert mode in Kodi settings?. IIRC the pass-through settings for individual formats aren't exposed in the standard settings level, and if they're not enabled and there's no DTS core audio to fall back to in media, there'll be silence.
-
-
I put a note in the wiki article about Samba server and Kodi SMB client being separate things. Other than that I wouldn't document the client from a security perspective as this is making outbound connections (not receiving inbound) so it's not contributing to the attack-surface of an installation.
LE is loosly based on https://www.linuxfromscratch.org/ principles if you want to read up. Brace yourself for an exciting read
-
Code
Jan 07 20:45:54.278148 LibreELEC kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] ... Jan 07 20:45:54.290312 LibreELEC kernel: [drm] Initialized meson 1.0.0 for d0100000.vpu on minor 0 Jan 07 20:45:54.290363 LibreELEC kernel: Console: switching to colour frame buffer device 240x67 Jan 07 20:45:54.290917 LibreELEC kernel: meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device
Nope, that's the moment 0.12 seconds after kernel boot when the simplefb device used during early stage boot is unloaded and the kernel switches to the meson (Amlogic) fb device provided by the VPU on the SoC which is now ready for use.
There is nothing helpful in the logs at this point and garbear understands what the overall issue is about. You can stop guessing.
-
Open a separate thread about the remote issue. Keep it focussed on technical details (no need for the install life-story).
-
I created https://wiki.libreelec.tv/installation/security in the install section so it's more visible. This is public documentation that can be added-to by anyone who cares enough to make the effort.