Posts by Elicity

    Okay, good to know. I'm no expert, I just used the descriptions from the board itself:

    So the HDMI-A-1 is the HDMI0 port on board ?

    Afaict setting the hotplug value might work for him.


    As a last resort I found in /flash/config.txt which could be related, but IDK.

    # Don't send initial active source message.
    # Avoids bringing CEC (enabled TV) out of standby and channel switch when
    # rebooting.
    hdmi_ignore_cec_init=1

    Try the latest nightly from 2025-04-16, it solved a bunch of issues for me:
    Its at the bottom of the nightly page: https://test.libreelec.tv/12.0/RPi/RPi5/
    LibreELEC-RPi5.aarch64-12.0-nightly-20250416-e25b5e0.img.gz (sha256) 2025-04-16 15:44 143.5M

    I used the official hdmi-cable from RPI, so I could have 4K@60hz with my SamsungTV (2024).
    All works just fine here /shrug

    edit 1:

    I could reproduce some I think: I use the HDMI-0 (closest to power-port), when I use the other one HDMI-1 the CEC does not work.

    edit 2:

    I tried changing HDMI-port number from 1 to 2 , that did not work
    I tried changing physical address from 0 to 1 and 2 but that did not work either. (assuming those are addresses?)

    So I went to the pulse-eight website to get some clarification on the options: https://libcec.pulse-eight.com/FAQ/Index/104
    * HDMI port number: the HDMI port number that you connected the CEC adapter to on your TV or AVR. (Default: 1)
    * Connected to HDMI device: the logical address of the HDMI device that you connected the CEC adapter to. 0 for TV, 5 for an AVR (Default: 0)
    So a bit of a dead end there.


    Then I went to https://github.com/Pulse-Eight/libcec and under vendor specific notes:

    Raspberry Pi

    • If your TV cannot detect the Raspberry Pi's CEC, or if the the Pi can't detect the TV, try adding the following line in /boot/config.txt and reboot the Pi: hdmi_force_hotplug=1


    So that might be an option, but I cant test it because it works fine here on HDMI-0 just not HDMI-1


    Good luck !

    balbes150

    So I can confirm this works on the NanoPi-r6C

    I have no experience installing u-boot, but with some dd magic and pure luck I got it to boot, albeit with an outdated/limited device tree so I have no audio atm. (although i see it loading the current dtb in the log). But it boots and it was fun to see that it works.

    Code
    After examination:
    00000000	MBR
    00008000	RKNS/idbloader/bootloader
    00800000	u-boot
    00C00000	trust.img

    So I used the OpenWRT image and skipped the EFI/MBR part and wrote from 0x8000 to 0x00c00000 (12M)

    Code
    $ dd if=owrt bs=1 skip=$((0x8000)) count=$((0x00c00000-0x8000)) seek=$((0x8000)) of=/dev/sda
    12550144+0 records in
    12550144+0 records out
    12550144 bytes (13 MB, 12 MiB) copied, 20,1171 s, 624 kB/s
    $ 

    Bootlog:

    NanoPi-r6c won't boot

    Steps I took:

    1. Booted OpenWRT (link) to test if debug-console was working and it was.

    screen /dev/ttyUSB0 1500000

    2. Verified checksum successfully:

    2186b184bb88272b2522841679b3bc99a7a7ae9aa376cc3d4b375b12381c4919

     LibreELEC-ARMv8.aarch64-13.0-devel-20250607193042-e5590fa-rk3588-roc-pc.img.gz

    3. Wrote test-image to sdcard and changed FTD to NanoPi-r6c

    $ diff extlinux.conf extlinux.conf.bak 
    3c3
    <   FDT /dtb/rockchip/rk3588s-nanopi-r6c.dtb
    ---
    >   FDT /dtb/rockchip/rk3588s-roc-pc.dtb

    4. Inserted sdcard into NanoP, no output on debug-console, unfortunately it does not boot.


    Thanks for all the hard work.

    Take a look, I'm not that versed in video tech but its x265 hevc if those are the right terms.

    Attachment triggers the GUI-palet shift on rpi5.

    Most colors switch to a "brighter" version of themselves, but its best seen if you select "brown" under settings>interface>skin>colors

    In the GUI brown just switches to red when playing that file.

    Afaict its just a one off after I tested more x265 and they do not seem to have this issue.

    However converting it to a different container or with different encoder does not seem to matter.

    The problems shifts along, its weird.

    I'll put in a request, referring to this thread.

    The GUI-colors are off too while playing, its weird :D

    So I thought I'd take some screenshots, to show the issue. Now here comes the kicker: they are snapped when colors are not right, but display fine when I look at them. When I play x265 GUI-colors are off, when I select another video-type x264, the GUI-colors snap back.

    There is another underlying issue. Maybe driver related idk.


    Thanks for all the help, its awesome!

    If you try to play this in any version of Kodi released since March 18 it will immediately crash Kodi hard. If it doesn't for you than maybe it is GPU related although I don't think Kodi uses the GPU for that kind of file, as best I could tell all the decoding was done in software.

    I tried on latest LE12 nightly (2025-04-04) and it works just fine. It uses SW decoding because of YUV422, but if you want HW decoding and save tons of space convert it using:

    Code
    ffmpeg -i test_recording.ts -acodec copy -pix_fmt yuv420p10le -c:v hevc test_recording.mp4

    This will reduce it to ~3.5mb which is a 93% reduction or ~16x smaller.

    -rw-r--r-- 1 kodi kodi 54689388 Apr 7 01:15 /dev/shm/test_recording.ts
    -rw-r--r-- 1 kodi kodi 3453886 Apr 7 01:22 /dev/shm/test_recording.mp4

    :)

    HiassofT Thank you very much, you guys are too fast ^^


    edit:

    So I updated to latest LE12 (2025-04-04), Immediately for some constructive feedback.

    The black screen problem has been fixed, yay!

    However the other issue i still present:

    Everything works fine except for Zoom Mode, when I cycle to that nothing happens. If I do it from the video-menu it does work, but I have to increase or decrease the percentage and set it back.

    (afaict the zoom value is not applied when switching to zoom mode)