Posts by chewitt

  • nVidia Nouveau Driver

    On an RPi5 (and cross-checked on AMLGX, both are GBM) the Kodi debug log shows this sequence:

    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:

    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:

    Code
    Jan 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:

    Code
    echo "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.

  • want to add more fav folder

    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.

  • [RPi4] Shared kodi database not working with LE12

    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.

  • Possible security breach

    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 :)

  • [Odroid-C2] RetroPlayer Problem

    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.

  • [Odroid-C2] RetroPlayer Problem

    Quote from Da Flex

    I think the cause is a GPU driver issue (missing mali regulator, crash log):

    That's a wrong guess (and if you don't know the answer, don't guess). Amlogic hardware has no Mali regulators so the frequency scaling code in the Mali probe/initialisation code correctly cannot find them and throws an error, which is harmless. Tweaking the kernel code to stop bogus user reports of GPU bugs is something I'd like to solve, but it's harder than it looks.

    I've asked Q's to garbear who maintains Kodi retroplayer.

  • nVidia Nouveau Driver

    In syslinux.cfg you can set "boot=/dev/sda1 disk=/dev/sda2" where /dev/sda1 is the /flash (boot) partition, and /dev/sda2 will be used for the /storage. You can also mount using disk labels, e.g. "boot=LABEL=LIBREELEC" or UUIDs. The full list of boot flags is a mix of LE specific things (read the 'init' script which is in the initramfs, see in the busybox package) and kernel things, which will be covered by kernel documentation on boot params. I would recommend configuring the PC to boot from USB and leave it that way until something works.

    Back on-topic:

    The fact we see some variant of failing to create an EGL surface under both display environments perhaps hints to something in-common between them. LE uses OpenGL-ES for Generic (GBM) and OpenGL for Generic-Legacy (X11) images. Both environments leverage mesa, but in different ways. I know mglae is already thinking about a mesa bug, and I'm starting to wonder the same.

    I pushed changes to the patch so "Nouveau" is now GBM, and I added "Nouveau-Legacy" which uses X11 (as you've been testing). I'm currently building both, which is normally around 40 mins/image for me.

    EDIT: I pushed both images here: https://chewitt.libreelec.tv/testing

  • [Odroid-C2] H264 Playback

    C2 is the most popular AMLGX board. Not huge numbers, but enough that a negative change between releases would show up in forum reports (despite the effort to downplay expectations with AMLGX). If you have media that reliably reproduces a problem with the current LE13 nightlies, I'd appreciate an extract or copy for testing.

  • [Odroid-C2] RetroPlayer Problem

    Quote from Da Flex

    At devs: Is that normal for Odroid-C2?

    Yup, 100% of AMLGX installs show it and it's completely harmless.

    Quote from Da Flex

    To me it looks like a general buffer issue on Odroid-C2:

    Nope, there is no such thing as a "general buffer issue" and we're grabbing at straws with that comment.

    qazy Please update to the latest LE13 nightly. I haven't touched the LE12 codebase in a while and any investigating and fixing needs to focus on the current codebase I'm poking. I have a hunch the error messages are generated by mesa, but it's probably reporting an issue with the underlying Linux DRM layer (where things like stride and buffers are handled). It may be something related to 'canvas' setup.

  • [RPi5] Aeon Skin

    LE 9.2.8 shipped in July 2021 so it has zero support for the RPi5 hardware released 2+ years later in September 2023, and the change from legacy RPi decoders (OMX, MMAL, etc.) in 9.x to GBM/V4L2 in 10.x onwards means you can't even frankenstein something with the old codebase and newer kernel/firmware (without foregoing all hardware decoding).