Yes, it's currently not a solution for your situation, but it looks much better. The timeout looks realistic and the different can clearly identified. So it should be technical possible to fix the issue via firmware. I have seen at the Cello webpages, that the remote control has a mouse mode. Does it make a different if you switch on/off this feature after you switched to the HDMI input?
Just to be sure, since you didn't start with a fresh install. Can you remember if you created an edid.bin file via getedid at some point in the past that might have remained in the directory structure (ls -la /storage/.config/firmware/edid/edid.bin)? If so, remove that via getedid delete and reboot.
Have you already tried a different HDMI port on your TV?
Posts by HarryH
-
-
Has the output of the cec-client changed in regards to the 2 things I mentioned? I assume you only get 1 event when you hold down the button, not multiple, right?
Do you have already checked if a newer firmware version for your Cello TV is available?
-
Theoretically yes, if you put the image file in the /storage/.update directory and then reboot. Please make a backup before.
The main problem could be that you have to reinstall additional add-ons because the architecture for the RPi4/5 has been changed from arm to aarch64. This is the reason why it is not recommended to go this way.PostRE: [RPi4] Update to LE 12.x
LE10/11 use 'arm' userspace and LE12 uses 'aarch64' userspace. The LE11 settings add-on is not showing an update because there is no 'arm' update. This also stops users from blindly updating and experiencing crashes due to arch-incompatible binary add-ons.
To do an in-place update you will need to first uninstall all binary add-ons (keeping their config). Then manually download (wget) the LE12.0.2 .tar update file to /storage/.update and reboot to update. Once the update completes you can…
chewittJanuary 29, 2025 at 6:07 AM -
Can you try it with a recent LE 12.0.2 from a spare SD card whether it behave different?
-
This part looks strange to me, or better: is different to the behaviour I know from my SONY TVs.
(rel:500,rep:0,prs:500,rel:0)
The prs: counter increases continuously by 1, starting at 1, as long as I hold down a button. In your case, it seems to be fixed to 500. Also timeout:30222488ms looks wrong -> 8h 24min.
Which RPi do you have and which LE version do you currently use?
-
You can also use cec-client to get more CEC details than with the KODI debug logging.
- Stop KODI process: systemctl stop kodi
- Start CEC client: cec-client
This CLI client will announced as "CECTester" on the TV. Depending on the behaviour of the TV it could be necessary to switch to the selected HDMI port again, to get CEC to work.
In general it's sometimes a good idea to disconnect the HDMI devices and TV physical and make all the components powerless simultaneous for some minutes. Afterwards the HDMI handshake will be initiated again and sometimes the CEC issues are like "magical" blown away.
-
Appears like a firmware issue of your Cello TV. To diagnostic what happens in detail, you could enable the KODI debug logging and watch with tail -F /storage/.kodi/temp/kodi.log which key events will be received from your TV via CEC during you held the up/down arrow keys and if there is a different to left/right arrow keys.
Some TVs interprets a long press signal from the remote control as a different function or the remote control sends a different key instead of repeating. If there is send a different key via CEC, then you could map this to Channel Up / Down to have page wise scrolling to mitigate the issue. -
Try and play a little bit with these settings for the CEC adapter:
- Remote button press repeat rate (ms): 100
- Remote button press delay before repeating (ms): 200
- Remote button press release time (ms): 0
Settings -> System -> Input -> Peripherals -> CEC Adapter
-
My experiences: some VC1 Bluray releases for example "The Bucket List" or "The Red Baron" are not playable fluent anymore, since the VC1 hardware decoder has been dropped with RPi4. Overclocking the RPi4 above 2.1 GHz also seems to make it fast enough to decode these titles via software, but it's like riding the razor's edge as to whether these settings are stable enough to enjoy the movie.
-
It appears that you have a 2712D0 hardware revision, so you need to install LE 12.0.2 or LE13. Apart from some nightlies, the required Mesa version you need for your RPi5 was not included before LE 12.0.2. This will fix the graphical issues.
-
Version 1.1.11 released:
- multi language support via KODI Weblate added
- new GUI languages: Polish, Spanish, Swedish
-
If you want support from experienced users or from experts like chewitt , you shouldn't skim with information. Snippets of logs are in 99.99 percent are pointless and and results into same as if you post "something is going wrong" - nothing more, no helpful content. Please provide a full debug log like described above.
-
Regarding "libreelec configuration error.", it contains no information which kind of error occurs. The usual way to report errors is:
- Enable debug logging
- Reboot
- Reproduce the issue
- Paste the log and provide the URL afterwards
-
Within KODI. The menu path is: Settings(gear wheel) -> Services -> UPnP/DLNA
-
Do you have an LG TV and does that also happen if you disable UPnP?
PostRE: Persistent Hourly Restart Issue on Raspberry Pi 4 with LibreELEC
The crash is from:
(Code, 5 lines)
PLT seems to be a uPnP library, so you could try disabling it in system/services/UPnP/DLNApopcornmixApril 24, 2024 at 2:56 PM -
Version 1.1.10 released:
- regression: shutdown does not work properly if the settings.xml file is incomplete or missing
This should fixes the issue reported by Gwin. The PRs have been created to provide this version via LibreELEC add-ons repo as well.
-
I was able to find 2 possible causes for the reported switch-off problem. Both situations can be prevented/fixed if the settings dialogue of the add-on has been closed once with OK (this will create/update the required settings.xml). I will provide an updated version of the add-on to fix the problem permanently.
-
Perhaps I should take another look at this. The shutdown script expects the setting value (false/true) to be present. There may be an edge case that I didn't stumble across in my tests.
EDIT:
I assume you had a previous version already installed and updated to 1.1.9. Can you remember your workflow? Did you have opened the add-on settings afterwards and left the menu with OK at least once, before you observed the failing shutdown?
Has anyone else observed the same misbehavior?