Posts by HarryH

Quote from ApexDE

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.

chewitt ,

the AMLGX image works for RPi5 too?

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:

• bootloader config / EEPROM

  Code

  PSU_MAX_CURRENT=5000
  BOOT_ORDER=0xf416

  https://www.raspberrypi.com/documentation/…html#BOOT_ORDER

• config.txt

  Code

  usb_max_current_enable=1

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

Nice finding.
But if you look at /flash, there is currently only kernel.img available. You will need a custom build for this test.

You can find the file here: /flash/cmdline.txt

Your Pi has no real-time clock, so the 2024-02-27 is the generated fake date during boot until it get a time synchronization via network. The kernel log messages are from your last startup (2024-05-31).

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:

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.

Quote from WarpLover

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.

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

Quote from WarpLover

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.

Hi Goood ,

please use the rpi-eeprom-config command with the edit parameter:
rpi-eeprom-config --edit or rpi-eeprom-config -e

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.

WarpLover ,

these settings should only needed, if the Power Delivery negotiation between RPi5 and the power supply isn't possible or disturbed. Do you use a case like the Argon ONE or another gadget like RemotePi board for your RPi5?

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?

Hi tomstephens89 ,

some questions…

• Are you using a case for your RPi4?
• Do you have tried also another micro HDMI to HDMI adapter, if you use one?
• This could be ambiguous: HDMI 1 of „HDMI 0 + HDMI 1“ or „HDMI 1 + HDMI 2“ ?
• Perhaps you can provide a debug log?

By the way, the period key on the left of the number pad is assigned to the context menu by default.

Are you sure that you edit in the right directory ?

Your add-on with the settings.xml file for defining the GUI items should be located here: /storage/.kodi/addons/script.test

Add-on structure - Official Kodi Wiki

In the directory /storage/.kodi/userdata/addon_data/script.test , there should only be the corresponding settings.xml file for saving values and will be generated automatically.

I think the missing part is <group></group> as a wrapper for setting. Its mandatory also if you doesn‘t have more than 1 group.

<?xml version="1.0" ?>
<settings version="1">
	<section id="service.test">
		<category id="generic" label="Generic" help="Help!">
			<group id="1" label="">
				<setting id="file" type="video" label="File" help="Select the video file">
				</setting>
			</group>
		</category>
	</section>
</settings>

The linked thread is correct because the TV is the receiver of the IR signals and sends a button code (the duration info seems not parsed or reliable) to the RPi5 via CEC.

Technically possible, but I don't expect this behavior on a TV:
If the TV interprets the buttons based on how long they were held down, it may be sending a different CEC button code.

The important part regarding the breaking change seems the Android/Google TV generation. Previous generations of SONY TVs are able to passthrough the tuning and menu keys to CEC, if you configure this in the Bravia Sync settings for external inputs.
After switching to a newer TV of the same brand, I'm facing for the issue, that the menu keys and some other keys aren't passthrough anymore. Before it was possible to use the channel-up/down keys to navigate page wise through long listings. Now it's possible to open an additional menu for HDMI via info key and send a CEC command in behalf of the TV, but this key was also usable before directly.

My workaround is currently to move one step to right in the movie list to focus the scroll bar and move then with the cursor keys to jump to the next page(s) faster.

If this, that you meant with slow scrolling, perhaps you should map one of the color keys to the channel-up/down function. If not, you can only try to play a little bit with the CEC settings at System -> Input -> Peripherals.

To check which keys are going passthrough via CEC with your TV, you can stop KODI and use the cec-client command.

• Stop KODI
  systemctl stop kodi
• Start the CEC-client
  cec-client

• Press the keys on your remote control step by step and write down a list of all available keys. Here an example for cursor right:

  Code

  DEBUG:   [          189968]     SetCurrentButton right (4) D:0ms cur:17f
  DEBUG:   [          189968]     key pressed: right (4) current(ff) duration(0)

• Stop the cec-client process with CTRL-C
• Start KODI again
  systemctl start kodi

With that information you can make then the changes like you want to the keymap file.

EDIT:
I played a little bit with the settings (System -> Input -> Peripherals -> CEC Adapter) and could clarify 2 things:

• Set „Remote button press repeat rate (ms)“ to 100ms fixes the „slow“ repeat rate compared to a IR remote control.
  Reducing "Remote button press delay before repeating (ms)" to 200 makes it even faster to switch in repeat mode (scrolling), but could be make some trouble if there is "longpress" support in the future.
• It‘s important to switch the TV to the HDMI sub input/device -> "Kodi HDMI 1 Player" not only "HDMI 1" to get the tuning and number keys to work.