Posts by HarryH

    LybsterKodi,

    you skimp a little bit on detailed information, so it's like looking into a crystal ball.

    I don't assume this is the solution for the Options button over CEC, but do you know the Panasonic specific behavior (should also be explained in the manual)?: https://github.com/Pulse-Eight/libcec

    Hint: If available, try some other buttons (the period key for SONY Android TVs, RETURN at old Samsung TVs) on your remote if this triggers the ContextMenu by default.

    The recommendation of Da Flex is sometimes the only workable way if the chosen TV doesn't pass through the menu keys via CEC.

    "KEY_KBDILLUMDOWN" ???
    The linux keys you can find here:

    linux/input-event-codes.h at master · torvalds/linux
    Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.
    github.com


    I think the way via kodi.log or ir-keytable is more promisioning:
    List of keynames - Official Kodi Wiki

    xbmc/xbmc/input/keyboard/XBMC_keysym.h at master · xbmc/xbmc
    Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…
    github.com
    xbmc/xbmc/input/keyboard/XBMC_vkeys.h at master · xbmc/xbmc
    Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…
    github.com
    xbmc/xbmc/input/keyboard/XBMC_keytable.cpp at master · xbmc/xbmc
    Kodi is an award-winning free and open source home theater/media center software and entertainment hub for digital media. With its beautiful interface and…
    github.com

    so, if i add a NVMe SSD to the Argon case it will be booted by default? (over the microSD being in place?)

    I can't answer that with certainty. I don't have a RPi5 myself. But I know that many things have changed in the bootloader and to many users fiddling with outdated parameters. Therefore my recommendation is to start with the only needed settings.

    Because some weeks ago the official M.2 HAT+ (incl. specification) was published and advertised to automatically add the NVMe as boot device if detected, I'm expect that booting from NVMe is now also possible via default. Maybe this works with HAT+ only, and therefore not with the Argon ONE V3.
    However, to persist the boot order like you want, I would prefer to set it via EEPROM.
    EDIT: The advertisement was misleading, the official M.2 HAT+ requires too, to set the boot order in EEPROM like I described above.

    If you need additional settings like PCIE_PROBE=1 or dtparam=pciex1 / dtparam=nvme to get it detected, then it indicates your bootloader is very outdated or your chosen NVMe not compatible.

    With the official 27W PSU, a current bootloader (>= 2024-02-16) in your RPi5 and 100% compatible NVMe you don't need to change anything, because the autodetection should work and tells the kernel all things regarding the PCIe.

    Since the Argon ONE V3 does not support the PD handshake internally, these settings are necessary to provide enough power and add the NVMe as a boot device:

    If all things work fine and after some days without errors in the kernel log, you could force the PCIe to Gen 3 if you want speed up. But this is alltime out of the current certification for the RPi5 and should observed as a kind of overclocking. Some kind of NVMe seems to need this to (maybe a firmware bug ?):

    • config.txt

      Code
      dtparam=pciex1_gen=3

    It's good that you hold some spare parts in the back hand. In the last months I have seen some log snippets with much more noise regarding this message:

    Code
    May 31 11:08:04.570436 RPi5a kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
    May 31 11:08:04.570750 RPi5a kernel: nvme nvme0: Does your device have a faulty power saving mode enabled?
    May 31 11:08:04.570864 RPi5a kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug
    May 31 11:08:04.657093 RPi5a kernel: nvme 0000:01:00.0: enabling device (0000 -> 0002)
    May 31 11:08:04.657277 RPi5a kernel: nvme nvme0: Shutdown timeout set to 8 seconds
    May 31 11:08:04.660439 RPi5a kernel: nvme nvme0: 4/0/0 default/read/poll queues
    May 31 11:08:04.670425 RPi5a kernel: nvme nvme0: Ignoring bogus Namespace Identifiers

    Yes, at normal desktop computer I wouldn't expect such messages regulary. But also NVMe firmware isn't free of issues. At the RPi5 I know about cases, that it could fixed, if they followed the recommendation and add this to the kernel line in the cmdline.txt.
    pcie_aspm=off
    Maybe you doesn't need another cable in your current configuration. But you should give it a shot, and check if it disappears after exchange the cabeling.

    Would there be any value in replacing the Rpi5 with the RockPro64, turn on logging, and run it until it reboots? And would those results shed any light on what is going on with the Pi? (as a reminder, the rock sbc randomly reboots in the same way, which is why I bought the pi).

    I think you could make that as a cross check and confirm if it really made a reboot or "only" crash of KODI. The latter one could be ends with some needed changes in KODI it self to fix that.
    First you could try to start with a fresh installation of LE (for example on a new SD card) without additional add-ons (back to the roots) and try to reproduce the issue. In some thread I have read last days, it rumours that a weather add-on triggered some issues in the background.

    PS: You are right, it's always after midnight. :D

    As far as I know:

    • The volume control depends on the libCEC Adapter settings at "Settings->Input->Peripherals->CEC adapter".
      The corresponding settings file is there: /storage/.kodi/userdata/peripheral_data/cec_CEC_Adapter.xml
    • The internal volume control is disabled, if you set the audio to passthrough. But passthrough could be disabled from backside if "Sync playback to display" is active. Don't know if such settings influences the CEC volume control too.
    • The most use case for CEC is to steering with the TV remote control the downstream devices. Also the volume control of AVR / soundbar works like that. The way to control the TV volume seems not supported in all cases. But you could check to ensure that your TV supports that:
      echo 'volup 0.0.0.0' | cec-client -s -d 1
      echo 'voldown 0.0.0.0' | cec-client -s -d 1

    I am about to build another RPi5 system for a gift once the parts arrive. It will be in a Argon ONE v3 nvme case. I sure hope that is not going to have gremlins.

    Sorry for that, but this wording in combination with that case I immediately remember: "... Don't get them wet. Do not feed (install) them after midnight. ..." ;)

    WarpLover ,
    I don't know if you want to use the Argon ONE V3 for LibreELEC or some other use case. But if you want to start directly with LE you should ensure manually that the settings, which you grabbed from the PVR thread, are there. Normally this will already happens if you follow the instructions from the manual. However, the steps described in the manual to run the scripts are intended for PiOS etc. and only partially work with LE.

    To avoid sleepless nights I would start with a installation at SD card as first attempt, because the NVMe support is very sensitive regarding flexible pcb, NVMe model, bootloader version ...

    Most buyers with NVMe issues seem to think it's just an issue with this case, but in my opinion external PCIe on RPi5 in general is a ride on a razor's edge with so many factors that can negatively affect it. The other concerns (reputation) regarding quality assurance/support are just an additional factor.

    But: If you get a properly manufactured, I think the person that will get the gift will be very happy.

    Regarding your original issue:

    "Reboot" implies a reboot of the operating system, triggered by a normal shutdown, reset, power fail and so on. Your current situation looks like that only KODI was crashed and restarted after that. Indeed this looks like a reboot, because LibreELEC is very fast at startup. But it makes a huge difference for troubleshooting.
    You can simple check that after such event, if you connect to the console via SSH and use 'uptime' to see how long the operating system is up.

    I know that KODI with the current versions of LE12/13 crashes if the played video stream has some defective frames and additional software deinterlacing is on. If the hardware acceleration for deinterlacing is in use, there is a pixelation at this points, but KODI doesn't crash.
    Because you reported the issue with 2 systems, maybe you triggers the issue with the content you play or a installed add-on/skin.

    So the output looks that CEC is working at hardware and driver level. You can test some CEC commands to switch your connected TV On/Standby/Off like described here: https://pimylifeup.com/raspberrypi-hdmi-cec/

    To test if your TV passthrough the remote control keys to the RPi, simple start cec-client without any switches and look for key_press events. If that works, you only have some issues with your KODI installation/settings. That kind of issues can isolated with debug logging enabled and additional components logging is enabled for libCEC.

    If chewitt serious recommendation don‘t ends in a success, you can stop KODI and afterwards check CEC directly.

    • stop KODI
      systemctl stop kodi
    • scan CEC bus
      echo 'scan' | cec-client -s -d 1

    Because I have seen, that you also tested something regarding the 4K/60 issue in combination with your Denon AVR: Maybe you have a outdated copy of EDID data locally?