Just run "sudo apt install kodi21" on RPiOS Bookworm. (installing kodi will get the older kodi 20).
If you really need to build your own version, then see here.
Just run "sudo apt install kodi21" on RPiOS Bookworm. (installing kodi will get the older kodi 20).
If you really need to build your own version, then see here.
Might be worth reading through https://github.com/xbmc/xbmc/pull/25813
It sounds like the default behaviour of some types of subtitle has changed.
It's not clear to me whether this is a regression, or a correction to behaviour.
Might be worth finding a nightly from just before and just after that PR went in, to confirm if that was the cause of the change you see.
I started 3 movies. The first 2 were mpeg-2 and h264 had no problems, the third was h265 and worked until the moment I opened the menu. The picture wasn't affected in any way but the sound suddenly stopped (the AVR's indicators for Dolby-HD/Dolby Atmos went out), that's when I ran "dmesg | pastebinit":
Nothing unusual in there.
No real ideas. After a failure run "dmesg | pastebinit" and post the url just to see if anything complained in the kernel.
If it were me, I might try adding "force_turbo=1" to /flash/config.txt.
If that didn't work, I might try a core_freq overclock (note: too high and this could crash - backup before experimenting).
Start with core_freq=600 (but you could try 700 or 800).
How come my battery powered 2018 Snapdragon sdm845 armv8 64-bit processor can handle fluid 1080p AV1 10-bit video and my latest nightly Libreelec 3A turbo=1 1800-Mhz powered RPI4 8Gb RAM can't?
Your phone is running at 2800MHz, has an extra 4 cores, and cost far more than the pi 4 is probably the reason.
In my testing with 1080p VC-1, pi5 can play pretty much anything.
Pi4 can play many titles, but it is close to the edge. High bitrate spikes, interlace and high frame rate (e.g 1080p60) will may cause issues.
You did it right. There is a chance that you have a hardware revision, which wasn't supported by LE 9.2.8 firmware (firmware is part of the LE image).
If it is this, you can install latest LE, copy firmware (bootcode.bin, start.elf, fixup.dat) somewhere safe.
Install LE 9.2.8, then copy the newer firmware back on.
popcornmix AFAIK it's hard-coded? .. or is there a way?
Yes, hardcoded in libcec.
Rebuilding with that line adjusted would probably work, but mglae's hack may work and be an easier fix.
It's not a LibreELEC issue because the bootloader diagnostic shows "EDID=none". That is a hardware issue.
It is either:
the hdmi display.
the hdmi cable (or adaptor if using one for full size to micro-hdmi)
the hdmi socket on pi
All tests should be done with no sdcard and using bootloader diagnostic display:
Try with other socket on pi. If hdmi1 also reports EDID=none then it's not the pi socket
Try connecting to another hdmi display. If you still get EDID=none then it's not the display but the cable.
If another display works then your display is not correctly reporting an edid.
If there's another hdmi socket, then try that. Otherwise report issue to you display manufacturer.
Not sure without digging but if so, the simple fix would be to copy bootcode.bin/start.elf/fixup.dat from a working new image to the 9.2.8 image and see if that helps.
Another possibility is general bug fixes and improvements have improved compatibility with that specific TV.
Can I change the eeprom option from LE itself or do i need to boot into rpi-os or raspbian ?
You can ssh in and run:
QuoteLike buying a car that intentionally leaks gas, just for those that want to pull a trailer. Seems like a design flaw workaround to me.
The issue is there exist HATs (not ones designed by RPi...) that can be damaged if 5V is provided (which comes straight from USB power connector) but 3V3 is not (which comes from PMIC which ideally would be powered off on shutdown).
So, yes it is a workaround, but not for a design flaw that the Pi created.
2GB is enough for LibreELEC.
You only need more if you want to run additional services (e.g. using docker).
There is no fix for what you linked. It is by design. By default power is available for HATs after a shutdown.
If you are not using a HAT that requires that you set POWER_OFF_ON_HALT=1 and get the lower power consumption.
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).
QuoteLE 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).