Yes, you should give it at try. The chip hardware was reworked to reduce the production costs for the RPi5 2GiB model. Maybe that change is responsible for the special handling and for new production lots of other models it's needed too now. Only a assumption...
EDIT:
The related change should this one https://github.com/LibreELEC/LibreELEC.tv/pull/9253
It depends more on the chip revision 2712C1 vs. 2712D0 than the memory size. But the RPi5 2GiB seems to be one of the first models with that revision and you could be affected by this.
Posts by HarryH
-
-
Do you use a RPi5 2GiB model? I can remember that you should use a current LE nightly to support that. I think the scrambled picture looks so...
-
I did that, but nothing changed.
Possible. So you say the only way to try is by buying a newer cable? Then I hope the 12€ are not for nothing
I can't make the decision in behalf of you or give a guarantee. For example I know that also cheap HDMI 1.4 cables was in the wild, which doesn't have the CEC pin connected.
Like Da Flex already mentioned right. You doesn't informed us which device you are using for LE. Because you should ensure that your LE12 device has a working CEC adapter implemented. If all things are ready, its also possible that you just chose a wrong HDMI input at your TV. Some old TVs supports CEC only at one of them. -
I thought, that you want some help to get a solution for your CEC issue.
No, 12.0.1 is not the last build, so i linked already a newer version which doesn't have the issue with 2 CEC Adapter entries. It's up to you to try it or not.The DENON supports also CEC by itself and reports as active device, so the TV can switch to HDMI 1. After that every single device connected to the DENON can signal as "active source". The last one started, wins.
Example:
TV (HDMI 1) <- DENON (HDMI 1) <- FireTV
.... DENON (HDMI 2) <- LibreELEC (KODI)
.... DENON (HDMI 3) <- Bluray
The TV exposes: "HDMI 1", "HDMI 1 Amazon FireTV", "HDMI 1 KODI...", "HDMI 1 Bluray"
The last 3 entries equals to HDMI 1, HDMI 2 and HDMI 3 of the DENON. So it's usual that you can steering only 1 of that devices with your TV remote control at the same time. It could be that the first entry ‘HDMI 1’ of the TV only passes the remote control buttons via CEC if the device connected there has reported itself as an ‘active’ source.To realise this, you only need a properly configured CEC adapter in LibreELEC 12.0.1+ and no other components that cause additional trouble. (such as cheaply made HDMI cables, firmware, etc.), no more and no less.
-
To fulfill the official HDMI-CEC specification you need cables which follows HDMI 1.2a (and upwards). Maybe your cables does already, because CEC was available for some device since 1.1, but not official. If you already tried, it could be that you have a cable, where the CEC pin is not connected and therefore doesn't work.
-
The behavior with multiple HDMI 1 entries is known to me with SONY Android TVs. There can some more sub devices displayed if you have additional CEC compatible devices connected to your DENON AVR. On that way you are able to switch between the different CEC sources on your AVR via TV remote. Also I can confirm that not all (but the most) CEC keys are working if the TV is only switched to "HDMI 1" and not to the sub entry "HDMI 1 KODI ...". Maybe you have installed a firmware update for the TV, so that something has been changed?
The TalkBack feature (if available) is disabled? https://www.sony.com/electronics/support/articles/00269974
Regarding the irritating double entries for the CEC adapter in the input settings menu, you should switch to a newer version than the official version 12.0.1, as this contains the fix: https://test.libreelec.tv/12.0/RPi/RPi5/…-0803b93.img.gz -
Both are non-native Linux file systems. Can you prepare a thumb drive with ext4 and test again? If you have no Linux to fill the stick with content directly, maybe you can copy from your laptop via network to it.
Note: All file systems on external drives (such as SD cards, USB sticks, etc.) are vulnerable during cached writes, so you should make sure that you do not remove the drive from the running system without taking special measures. For the test with ext4, I would recommend not unplugging the drive until the system has shut down properly. -
Which file system do you use for your thumb drives? Maybe this makes a different.
-
this will not fix the cause, but you can prevent the problem by bypassing gpiozero and using lgpio directly.
lg libraryPS: Your add-on project is currently not set to public.
-
Just a shot in the dark: Because you reported that your AVR switches automatically back to TV/SAT. Do you have tried with CEC disabled? Default is to report KODI as active source. Maybe something is going wrong with it in your current configuration.
-
I already posted the commands to collect some information. The last 3 lines of my previous post contains the commands to use via SSH console.
- lsblb -> list block devices
- lsusb -> list USB devices
- dmesg ... -> search for specific entries in the kernel message log
If it sounds like rocket science for you, then we will go beyond the scope of this thread.
Sorry, if I distracted you. I wanted to make sure that both physical drives are recognized correctly. Because this is important regardless of whether you use 2 individual drives or the spanned volume. But if you have created a spanned volume using the Windows functions, as chewitt has assumed, then you need all the things he has already described to get access to the whole volume. -
chewitt,
it looks to me, that the D4-320 works like a USB->SATA adapter with SATA port multiplier or something like that. Not as the "usual" JBOD volumes of simple software raid adapters. Maybe Gar90 should look for kernel messages regarding the USB devices first?lsusb
lsblk
dmesg | egrep -i "usb|ata|seagate" -
Please try this: Move the import line for os module upwards before you import from gpiozero and insert that line.
Pythonimport os os.environ['LG_WD'] = '/tmp' from gpiozero import PWMOutputDeviceLibreELEC 12 has been hardened. The lgpio module (used by gpiozero) needs a working directory path which isn't write protected: https://github.com/gpiozero/gpiozero/issues/1106
-
There are 2 things to note in your screenshots:
- You hasn't used the official supported power supply -> recommended: 5.1V / 5A via Power Delivery protocol
Other PSU can be unstable, because not ready for the fast load switches of the RPi5. - The bootloader is one of the first and outdated 2023-10-18 (current: 2024-09-10)
It's also important to know if you use a case like the Argon ONE V3, because this needs special handling.
But in general, please follow chewitt recommendation and try a new SD card first. - You hasn't used the official supported power supply -> recommended: 5.1V / 5A via Power Delivery protocol
-
According to this (2.6 Simultaneous Access):
Differences — rpi-lgpio 0.6 Documentation
https://rpi-lgpio.readthedocs.io/_/downloads/en/latest/pdf/the error messages indicate that the GPIO is already in use. Seems not a fault of the rpi-tools add-on.
-
Normal behavior of ntpd is to ignore time servers which are more than 1000 seconds away from the current time, maybe this has some influence in your situation.
-
If you have a RPi5 in use, please be aware that the gpiochip has been reordered back to gpiochip 0 with kernel version 6.6.45 and following.
Use gpiochip0 for the user-facing GPIOs on Pi 5 by pelwell · Pull Request #6144 · raspberrypi/linuxPi 5 contains multiple GPIO controllers; running gpiodetect shows that there are five. Prior to this patch set, they appear like this: gpiochip0…github.comlgpio pin factory is broken on RPi5 since kernel 6.6.45 · Issue #1166 · gpiozero/gpiozeroOperating system: e.g. RPiOS Bookworm Python version: 3.11.2 Pi model: Pi 5 GPIO Zero version: 2.0.1 Pin factory used: lgpio A recent change in the RPi kernel…github.comMaybe this is the issue for not working with 12.0.1.
-
Your configuration looks to me like common practice and in my opinion it normally should work.
I grabbed this from the known issues part of the GC110 firmware changelog:- Loop protection might not work between two Insight-managed switches.
Workaround: Disable IGMP snooping on at last one the switches. - When IGMP snooping or MLD snooping is globally enabled or enabled on a VLAN, unknown multicast packets are dropped for both IPv4 and IPv6 traffic.
Workaround: Disable both IGMP snooping and MLD snooping.
If you doesn't have the DHCP L2 Relay / DHCP snooping enabled and accidentally misconfigured, then there seems to be some other "features" available that can be trigger such issues too...
- Loop protection might not work between two Insight-managed switches.
