Posts by popcornmix

  • RPI400 - HDR

    The working edid is the typical two 128-byte blocks.

    The not-working edid is four 128-byte blocks which is unusual.

    Not sure if something changed in the 6.6 to 6.12 kernel bump that means the extra edid blocks are reported, and whether their presence causes any issue for display-info library.

    Looks like the first two blocks are the same. The additional blocks decode to:
    ```

  • RPI400 - HDR

    While trying to get HDR working, leave second hdmi disconnected to avoid complicating things.

    Can you post your edid? One way is to run:

    Code
    cat /sys/devices/platform/axi/axi:gpu/drm/card?/card?-HDMI-A-1/edid | hexdump -v -e '/1 "%02x"'

    and copy/paste the output.

  • RPI400 - HDR

    Not sure if this is related, but this is surprising:

    Code
    Connector 0 (33) HDMI-A-1 (connected)
  Encoder 0 (32) TMDS
    Crtc 3 (100) [email protected] 594.000 3840/176/88/296/+ 2160/8/10/72/+ 60 (60.00) P|D 
      Plane 6 (125) fb-id: 726 (crtcs: 1 2 3 4 5) 0,0 1920x1080 -> 0,0 3840x2160 (XR24 AR24 AB24 XB24 RG16 BG16 AR15 XR15 RG24 BG24 YU16 YV16 YU24 YV24 YU12 YV12 NV12 NV21 NV16 NV61 P030 XR30 AR30 AB30 XB30 RGB8 BGR8 XR12 AR12 XB12 AB12 BX12 BA12 RX12 RA12)
        FB 726 1920x1080 XR24
Connector 1 (42) HDMI-A-2 (connected)
  Encoder 1 (41) TMDS
    Crtc 4 (112) [email protected] 297.000 4096/1020/88/296/+ 2160/8/10/72/+ 24 (24.00) D 256:135

    Do you have a second hdmi display connected?

  • Question for 4K configuration according to Wiki

    The resolution list from kodi tends to be the list extracted from the edid, plus the mode kodi was launched in (internally denoted RES_DESKTOP). The latter of these shows as a duplicate.

    In some places (like setting the default resolution for the GUI) they behave differently. Consider choosing 1920x1080@60 vs RES_DESKTOP (which we'll assume was 1920x1080@60).

    e.g. if you connected to a different display that reported 1280x720@50 as it's preferred mode (but still supported 1920x1080@60) then choosing the former option would result in a 1920x1080@60 GUI resolution, whereas choosing the latter would result in 1280x720@50 GUI (this monitor's RES_DESKTOP).

    As kodi doesn't make it clear which is which in the GUI, this distinction is less useful.

    It would be better if in settings, RES_DESKTOP showed with a unique name (e.g. "DEFAULT").

    And it should probably be filtered out from whitelist.


    Your second duplicate resolution is probably the edid reporting two different modes with same refresh/timing, but some other differences (e.g. blanking period or aspect ratio).

    Code
    edid-decode /sys/devices/platform/axi/axi:gpu/drm/card?/card?-HDMI-A-1/edid

    may provide some clue.

  • [RPi5] No boot after EEPROM update

    Quote from Free Man

    There doesn't seem to be much in the way of instructions at that GitHub page on what to do and what to expect... Is this the expected result? Do I simply power down, replace it with my (previously functional) libreELEC SD and reboot?

    Yes - green screen means eeprom programmed correctly. Red screen means it failed.

    Docs are here.

    Quote

    When the green activity LED blinks with a steady pattern and the HDMI display shows a green screen, you have successfully written the bootloader

  • [x86-64] Trying to find the root of repeated crashes in the last month of nightlies

    Quote
    • This suggests Kodi is dying when trying to render some text from an addon (or skin element) while Python is executing.

    I don't see evidence for that from a single crash log. The font rendering thread is just what kodi was doing when other thread crashed with a SEGV. The crashed thread was python related. It's most likely just luck what other threads happen to be doing when the python thread crashes.

    As chewitt says:

    find the date of first nightly with the issue.

    find if you can provoke the issue with a clean .kodi

  • [RPi5] Rotate HDMI Output

    You might want to try installing kodi21 from RPiOS which supports wayland, and much like Xorg on the PC, allows the compositor (outside of Kodi's knowledge) to rotate the screen.

    Note that this will use EGL for composition, rather than DRM which is a less efficient path. It should be fine for 1080p60, but will struggle with 4K video.

    But you can give it a try quite easily, to see if it meets your requirements. Use the preferenced/screen configuration tool (from the desktop) to set the display rotation, then launch kodi (the desktop version, not the fullscreen version). You can switch the desktop kodi to use fullscreen when running.

  • [RPi4] Updating to LibreELEC 12.2

    Quote from elliottmc

    With that in the file, and the HDMI plugged in closest to the power cable, it does work, as long as the HDMI is plugged in at boot, and not afterwards.

    You should be using:

    video=HDMI-A-1:1920x1080M@60D

    The D means assume it's connected (otherwise you will need to have a display connected at boot).

    You should always use the primary hdmi connector (closest to power connector).

  • [RPi4] LG C3 OLED TV Only Working in PC Mode

    Quote from atcronin

    I wonder if this patch (done properly) could make it into the official repo? While it is a workaround for an LG TV bug, I am not sure the possibility of engaging PC mode would ever be preferable for a Kodi distro.

    Reporting a PC style device as a PC style device sounds like the correct behaviour.

    The TV not allowing the user to choose picture enhanced based based on this seems like the bug.

    I'd be nervous about changing the reported source type for everyone. I believe using PC mode will often default to a non-overscanned display which is desirable and the change you are suggesting may make things worse for others.

    The correct solution is to complain to LG and hopefully a firmware update will allow your use case to work.

    The workaround should be that the kernel defaults to PC mode. but allows a runtime override (perhaps through sysfs) to change the SPD_SDI type. A display settings option in kodi could allow setting this. But that is more work, and really needs to be done in the upstream linux and kodi repos, not by LibreELEC.

  • [RPi4] LG C3 OLED TV Only Working in PC Mode

    You can see the infoframe used:

    I'm guessing it's the "PC general" that causes the bad behaviour in your TV which is set here.

    This is generic linux kernel code, so all linux platforms will behave the same (assuming they support the spd infoframe).

    I'd say the code is correct. Based on the options available that is the best match for a Pi or PC.

    Changing from HDMI_SPD_SDI_PC to HDMI_SPD_SDI_UNKNOWN might avoid the issue with your TV, but it's not runtime configurable (you will need to patch that line in kernel and rebuild LibreELEC).

  • [RPi4] AAC Passthrough

    There is (effectively) no AAC passthrough anywhere.

    It is mentioned in specs, but n o consumer devices output it and kodi doesn't support it.

    Kodi can decode the 6-channel AAC and output 6-channel PCM.

    This is lossless and will have perfect quality, but relies on connection to AVR to support multichannel PCM.

    It's not clear from your post how the TV and AVR are connected.

    Ideally you connect pi-<hdmi>-AVR-<hdmi>-TV but it sounds like you are not (due to AVR not supporting 4K, but TV does).

    I assume you care connecting pi-<hdmi>-TV-<something>-AVR?

    What is the <something>? Is that ARC or toslink/spdif?

    They are limited to two-channel PCM. But two-channel PCM can carry passthrough of AC3 or DTS.

    (Note: AAC and AC3 are distinct formats).

    The good news is kodi can be configured to decode AAC, encode it to AC3 and output that as passthrough.

    That will likely get you multi-channel audio. The operation is lossy, but would be imperceptible to most people.


    In system/audio settings set:

    Number of channels: 2

    Allow passthrough: On

    Dolby Digital (AC3) capable receiver: On

    - Enable Dolby Digital (AC3) transcoding: On

    DTS capable receiver: Off (you could try on, but that is less commonly supported by TVs)