I think it's a problem with wrong RPi firmware (unknown/new hardware revision on RPi5):
This is harmless if you are not using PIO (and almost no one is).
The next LE kernel bump will demote it to an warning.
Updating the bootloader will also remove the complaint (but unlikely to affect this issue).
**************I pruned the file but it was still too big so I compressed it. It is actually kodi.log.gz not kodi.log*****************************kodi.log
-J
Don't enable the component specific debug unless asked for it - it just makes the log so large it's very hard to read.
But, the real answer is if you have an issue with a specific addon, then check out the addon's thread.
https://forum.kodi.tv/showthread.php?tid=364953
where it does sound like there is a known issue "All live channels freeze after just a few seconds".
I don't have an LG but does changing the name of the input (away from PC) help?
From here.
Are you using the primary hdmi connector? (The one closest to power connector).
Only that one supports CEC (on 12.0.2).
I've been looking into a case and will probably go with the Argon One which is both a massive heatsink and includes a configurable fan. I'll have to endure the fan for AV1 playback. Hopefully it won't be too annoying.
OTOH maybe the smarter alternative would be just to invest in a rpi5 instead of burning 25£ on an additional case.But when booting to LE isn't the bootloader firmware tied to the LE version? I'm not sure how to update it since that is the latest version shown to me.
I've had success with completely passive heatsink cases like the flirc one (which has a kodi branded variant).
There should be no tie between LE and bootloader. Latest bootloader will typically be fine for any images (even old ones).
Yes, the jumping is likely because video decode cannot keep up.
What you find is audio plays at correct speed, but video is playing slower, so a/v sink drifts apart.
Once a/v sync reaches a set threshold, kodi will seek (jump) to restart with audio back in sync (but it will obviously drift again).
Your bootloader version does pre-date automatic NUMA settings and SDRAM_BANKLOW will be ignored.
However looks like you are on a Pi4, so SDRAM_BANKLOW=3 was the default so it may not be critical, but it may be worth updating that to be sure.
Setting numa=fake=1 should get you back to pre-numa performance (which I'd expect to be a little lower, but may be worth a test).
LE 12 nightly-20250116-37e4458 - dav1d 1.4.1, Kodi 21 --> played fine on slow scenes, some "lag/drops" on fast paced scenes
LE 13 nightly-20250205-562de9e - dav1d 1.5.1, Kodi 22, NUMA --> playback keeps jumping every 4 seconds
It might be best to try and find a file that plays well on one of the systems but not the other (something where you can check a/v sync is accurate throughout). If the answer is "struggles on both", then it might just be slightly different thresholds in kodi makes one appear better (but really you can't easily judge which is better when both fail to keep up).
Note: Pi5 benefits significantly more from NUMA than Pi4 (and it's much faster to start with).
First make sure you are connected to primary hdmi port (hdmi0 - the one closest to power connection).
Next, disconnect TV from mains for several minutes.
Remove all HDMI connections, and just connect one HDMI from TV to Pi (no AVR etc).
Power on TV first, set to Pi's AV input, then power on Pi 4.
Does CEC remote work? If so you can try connecting the other hdmi devices..
I don't believe anything has changed in this area. Are you sure that downgrading back to 12.0.1 does change the behaviour compared to 12.0.2?
Can you ssh in and run "kmsprint" and "kmsprint -p" and post the output for both 12.0.1 and 12.0.2?
(without having run the modetest command chewitt suggested for this test).
Enable debug logging, then enable CEC in component specific logging. Reboot, cause the crash and post a new log.
Unfortunately the crash backtrace has no info. A debug build may be needed.
I'm not quite understanding what you wrote.
When does the crash occur? After it's been running happily for some time? (how long?)
Does the crash occur when you are doing a specific operation? (e.g. starting playback of a file? Navigating through menus? While system is idle?)
Finding the first nightly build with the problem is one way of narrowing things down.
Also, if you rename ~/.kodi and restart (so back to default settings) does it still crash?
- If I have a recording that triggers the crash on my side, I assume I should share that file?
Yes. Ideally cut it down to the minimum size that provokes the crash and upload it somewhere (e.g. google drive, or dropbox)
Apparently rotation via overlay was added in Kernel 6.6.63, I will test other parameters...
Don't spend too long on this. It's not going to succeed.
I believe the Touch Display 2 is natively portrait, and kodi doesn't support rotation through DRM so this is not going to work well even if you get the touchscreen working (presumably there are kernel commits missing).
Running RPiOS desktop, and using kodi21 from apt would support rotation I believe (but it's a less efficient render path).
I've been putting off upgrading to le13 because le12 is so stable - hope le13 is the same.
I've been running le13 as daily driver for months. I've had no problems.
Does this apply to the latest le12 nightly (LibreELEC-RPi5.aarch64-12.0-nightly-20241114-f000f3c.img.gz) or is it just the latest le13 nightly?
LE 13 only.
mattmarsden I guess you have to downgrade the firmware to the one, which was in use back in the days.
No, 9.2.8 predates the Pi4, so there is no older firmware that will work. I think you'll need to use a Pi3 to run 9.2.8.
With latest nightly, you can enable NUMA to get better performance. See numa thread.
Make sure bootloader is updated to latest and set:
SDRAM_BANKLOW=1 (for pi5)
SDRAM_BANKLOW=3 (for pi4)
using using rpi-eeprom-config.
From previous testing, on a pi5 I'd expect any 8-bit 1080p60 AV1 to play fine, and most 10-bit 1080p60.
1080p24/1080p30 will have no problems.
NUMA likely means any 10-bit 1080p60 will play on a Pi5.
Pi5 is around 2 to 2.5x the speed of Pi4, so Pi4 abilities will be lower.
I'd predict any 720p60 AV1 files to play okay, and some 1080p30 on a Pi4.
This seems to be the normal speed for that hardware. The NIC specs don't mean you really get it in real life.
No. The linked chewitt post reported:
I see transfers around ~112MB/s from an RPi5 with nvme storage.
112MB/s is 896Mbit/s, so very close to gigabit.
Yes - you can get close to gigabit real world speed from a Pi5 ethernet port.
This assumes the rest of the network devices and cables can handle gigabit.
