Posts by chewitt

  • [RK3588S] LE for Radxa Rock 5C

    The 5c image in my test share now has the patches RadxaNaoki linked (inc. the audio fix) above. The previous image only has the &hdmi0_sound node added, not the i2c node.

    If gnarlsnishi confirms all is working I'll push a kernel/patches update to official LE nightlies. I've been holding off bumping the kernel to 6.18-rcX as there were PCI issues in the initial rc releases, but those seem to be resolved upstream now.

    f1gogata no idea what the problem is but I've updated the branch with current patches and it works for me. NB: I'm building on an older Ubuntu 22.04.5 (LTS) host.

  • Nightly Builds

    Nightlies are created on a "best efforts" basis so there is no guarantee or promise of one being created every night. If there is no nightly there is no real need to post about it because 99% of the time any cancelling of nightly builds is our doing so we already know about it, and if something is broken we get alerts and know about it, and if there are no changes and thus no nightly to be built, we're enjoying some downtime and don't need the distraction of forum posts.

  • [RK3588S] LE for Radxa Rock 5C

    Code
    Oct 13 15:01:55.422594 LibreELEC kernel: dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
Oct 13 15:01:55.422709 LibreELEC kernel: rockchip-drm display-subsystem: [drm] HDMI Sink doesn't support RGB, something's wrong.

    ^ No idea what this means, but I have a hunch this is likely to be responsible.

  • [x86-64] XMOS USB DAC not instantly detected

    I've seen similar issues with ARM SoC boards and the typical solution there is changes to device-tree files to correctly describe the hardware (and how it is powered) but x86_64 hardware doesn't require/use device-tree things at all, so that's not relevant.

    No firmware is required for the internal USB hubs.

    Please update to the latest LE13 nightly and see if the newer kernel etc. in the image randomly fixes anything?

  • [RK3588S] LE for Radxa Rock 5C

    gnarlsnishi The only other difference I can see in hdmi0 nodes between Rock 5b (3588) and 5c (3588s) is something related to FRL support which is not (or should not be) linked to HDMI audio support. I've updated the rock5c image in my testing share so device-tree has the extra line though, but I can't see it changing anything. So:

    a) Put Kodi in debug mode, update to the latest 5c image in my test-share, reboot, then run "pastekodi" and share the URL so I can see some other things in the system log.

    b) If that didn't magically change something, edit extlinux.conf in the boot partition of the SD card and experiment with some other rk3588s board device-tree files (all are in the 'rockchip' folder on the SD card) and see what happens. Some might not boot. Some might not show HDMI either. If one does show HDMI audio .. let me know which one.

    EDIT: Wait 30 mins until I rebuilt and sync'ed new files!

    EDIT: Files are now posted..

  • [RK3588S] LE for Radxa Rock 5C

    gnarlsnishi I can see the device-tree for Rock 5A/5C is missing the &hdmi0_sound node so I think you will only see the Analogue audio output on the board? - If yes, the images in my test share have been updated to add that and HDMI audio should be visible. If you can test and confirm HDMI audio is now working (for PCM output) I'll send the patch/change upstream to the kernel.

  • Filebrowser Add-On password

    Filebrowser is an add-on not a Docker container. The default credential is admin/admin. If you changed them and forgot the details the easiest option is to uninstall the add-on, and when Kodi asks if you want to keep add-on settings, say 'no' and allow everything to be removed. Then reinstall the add-on and it will reinstall to defaults again. If you say 'yes' it will reinstall with the old (forgotten password) settings.

  • No passthrough to Sony MDR-HW700DS headphone decoder

    Kodi has standard/advanced/expert settings modes and standard hides some of the PT audio options. Are you using the higher ones? .. have you enabled True-HD pass-through?

    If yes to both I'd ask you to update to a current LE13 nightly and test again (and share a log using the pastebin function in the LE settings add-on) as this eliminates everything that got fixed since LE12.x; even if we find an issue on 12.x now the fix will be in 13.

  • NanoPi R3S-LTS

    Ahh, I'm not interested to add support for boards that nobody is using so it's not in the official list right now. The board appears to have upstream kernel and u-boot support so adding it is a trivial task. How it then works is a different set of questions; Rockchip is still maturing but moving in the right direction.

  • [x86-64] LE 12.2 doesn't boot on ASUS Chromebox (CN60)

    Are you talking about the OS configuration wizard in the Kodi GUI (system name, wifi, services, etc.) or the installer wizard used for selecting a target disk to install the OS to?

    If the former, this is good and the box is booting okay and you have a clean Kodi environment (as /storage/.kodi was renamed out of the way). This was intentional to ensure there is no conflicts with add-ons compiled for Xorg not GBM. You can restore the previous config by stopping Kodi and swapping the folders around again; or if there are any issues, by stopping Kodi and moving specific bits of config back again (add-on settings, sources, passwords, etc.). Binary add-ons like screensavers/visualisers compiled for the Generic Legacy (Xorg) image are not compatible with the Generic (GBM) image so I would normally suggest the partial restore option, or swap folders back but deliberately nuke /storage/.kodi/addons/* then reinstall add-ons.

    If the latter, no idea what's going on..

  • [RPi4] Issue with playing h.265

    Code
    ffmpeg[0x105b0020]:   Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, progressive), 3840x1606 [SAR 1:1 DAR 1920:803], 23.98 fps, 23.98 tbr, 1k tbn (default)

    The only unusual thing that I see is the resolution (3840x1606) which has an unusual height (aspect ratio) although later in the log Kodi is selecting the [email protected] mode in the whitelist. I'm wondering if the dimensions fall outside expected limits elsewhere in the video pipeline, e.g. sometimes drivers have hardcoded expectations on things being generally 16:9 or 4:3 ish.

    First thing to do in any case is update to a current LE13 nightly to eliminate everything fixed since 12/12.2. Any difference?