Posts by HarryH

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

https://wiki.libreelec.tv/support/log-files

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?

Post

RE: 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/DLNA

popcornmix

April 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?

Gwin,

thank you for the feedback. This should only happen if "Activate compatibility mode for ONE V1" is enabled, as this disables V3 support as described in the help text. Did you activate this by mistake?

The add-on is now also available for LE12 via the LibreELEC add-ons repo. It was automatically updated in the background, although it was previously a manually installed version 1.1.9. This happened shortly after the start without a confirmation dialogue appearing.
It was showing in the log that it was 1.1.9 during KODI startup but I couldn't reproduce that situation afterwards, maybe depends on the refresh of the repo inventory. This behaviour was unexpected, but it seems a good working mechanism.

chewitt , heitbaum ,
Many thanks for merging the 2 PRs.

Version 1.1.9 released:

• compatibility: some early MCU firmware versions could hang off after register support check
• added menu option to explicitly disable register support detection for ONE V1/Fan HAT

It would be nice if someone could test with a V1 case whether the effort for this switch was worthwhile and now helps to achieve a functioning fan control or whether it is useless.