Please test with the latest nightly build.
We've now updated to linux kernel 6.0 and won't be looking into issues anymore that once happened with kernel 5.15.
And please post full debug logs created with the "pastekodi" command or the log uploader function in LibreELEC settings.
Cut down logs or "me too" posts with no info don't help us.
https://wiki.libreelec.tv/support/log-files
so long,
Hias
Thanks a lot for the logs and also your edid!
I could reproduce the issue here, it comes from the speaker allocation block in your edid - it reports left, right and LFE (which is not totally wrong but a bit weird as your soundbar only support 2 channel PCM) - and then the hdmi audio driver and kodi trip over that.
The easiest workaround is to simply remove the offending speaker allocation block from the edid (you don't need it, it's only needed for multi-channel PCM output which your soundbar doesn't support)
You can do this eg with AW EDID Editor (there are other programs available but I found that to be the most reliable and easy to use one and it also runs fine under Wine)
First ssh in and run getedid create. This will dump your current edid, save it to /storage/.config/firmware/edid/edid-HDMI-A-1.bin
Then copy this file over to your PC, open it in AW EDID Editor, change to the "CEA Extension" tab and remove the "Speaker Allocation" entry in "Instantiated Blocks", and save the changed edid.
You can also use the modified edid in the attached zip (I used the edid you posted) but keep in mind that if you change the TV, HDMI ports etc it might not match anymore and you could run into CEC issues etc - in that case you have to do the steps above.
Now copy the modified edid back to your RPi, overwriting the existing /storage/.config/firmware/edid/edid-HDMI-A-1.bin file.
Then run create-edid-cpio on your RPi - this will update /flash/edid.cpio so the edid is available early during boot as well.
Now reboot and HD passthrough should work fine.
Note: if you switch to a different TV / soundbar / AVR / ... you have to remove the edid changes first - simply run getedid delete on your RPi and reboot to do that.
so long,
Hias
eLr0n can you please test with the latest LE10 nightly build from here:
https://test.libreelec.tv/10.0/RPi/RPi4/ - just copy the latest img.gz (currently 20221005) to the update share/folder and reboot.
If this doesn't help add "drm.debug=0x04" to the end of /flash/cmdline.txt (it must all be on a single line, immediately after "quiet", just separated by a blank), then reboot, reproduce the problem and upload a full log (either with the upload log file option in LibreELEC settings or via ssh with the "pastekodi" command) - just post the URL here.
The log should give more hints why it fails.
so long,
Hias
Did you maybe run "getedit create" at some point in time?
If yes, then RPi will still be using the old edid of your HD TV.
In this case simply run "getedid delete" and reboot.
so long,
Hias
Had a look at github issues, it's a known problem (Netflix changed APIs), new netflix plugin version with a fix should be released this weekend
so long,
Hias
This looks like a netflix or netflix plugin issue - report it on the netflix plugin repo
so long,
Hias
LE has no knowledge about the used kodi in an update and which addons might get disabled then by kodi. So there's no way we could tell you upfront what kodi will do.
If something goes wrong with a nightly then restore your backup - or stick to official release builds.
so long,
Hias
I think it's pretty obvious that installing development snapshots / nightly builds can result in anything - even non-booting systems.
So do that at your own risk and always have a full backup so you can easily roll back if something goes wrong.
so long,
Hias
Please provide a sample file that triggers the issue and a full debug log playing it (and showing the issue).
so long,
Hias
Glad you got it working!
so long,
Hias
I just tested on a clean installation with the latest LE10 nightly build https://test.libreelec.tv/10.0/RPi/RPi4/…-5504109.img.gz, changed distroconfig.txt, config.txt and cmdline.txt as outlined in my post you linked to and it worked fine (running on PAL, 720x576).
I suggest you do the same - the SD card came preinstalled with kodi and you upgraded to LE10 it could be there's some crap on the installation that prevents kodi from starting (and upgrading eg from 9.2 to 10 isn't supported at all - it can work but often it doesn't).
Also make sure everything in cmdline.txt is on a single line and you don't omit the "e" on the video setting - you have to use eg
video=Composite-1:720x576@50ie
otherwise you just see the LibreELEC splash screen - kodi will start but you don't see it's splash or GUI.
so long,
Hias
Please test with the latest LE10 nightly build from here
https://test.libreelec.tv/10.0/RPi/RPi4/
ISTR 10.0.2 had some (composite) bugs that are fixed now.
Editing distroconfig.txt isn't ideal (as it will be replaced on updates) but should work - better keep a copy of it when you got it working.
I've thought about better solutions like having a separate distroconfig-composite.txt but while working on that composite configuration in RPi kernel/devicetree changed again and I decided to wait a bit until things had settled.
so long,
Hias
popcornmix rebased his changes, PR with update to current kodi master is here:
so long,
Hias
You haven't enabled debug logging so it's a bit hard to tell what really went wrong in your case but my guess is this is the long standing issue with kodi trying to create too many scaled-down thumbnails on the fily and thus exhausting (graphics) memory.
You could try running texturecache.py c, this will take a while and create thumbnails in a way that shouldn't trigger the issue - after that browsing should work fine.
Increasing CMA memory (that's the kind used for graphics) could remedy the issue a bit, too but probably won't help as much as creating all thumbnails upfront - add eg dtoverlay=cma,cma-512 to the end of /flash/config.txt
so long,
Hias
ISTR there were issues when tvheadend is running on the same device where video is being played back.
It could be that the memory bandwidth required for deinterlacing interferes with operation of the USB DVB hardware and/or drivers and/or tvheadend - might be too short buffers (in HW or driver) or something similar in tvheadend like increased latency resulting in dropped buffers/packets.
I don't think a definitive solution for that was found, other than moving tvheadend (with the DVB receiver) to a separate device.
so long,
Hias
Hmm, just checked the sample on my Linux laptop with VLC and mpv and there are blocking artifacts at around 15-17 seconds - so there seems at least to be an issue with the recording. Do you see other artifacts at different timestamps with LE?
so long,
Hias
Thanks a lot for the sample!
I'm a bit busy with my daytime job ATM but I'll have a look the next couple of days, not sure if I manage to check before next weekend though.
so long,
Hias
