You could try:
and check if the system with the problem can now play videos (I suspect it will be able to).
If it is that suggests the problem is either settings (config files in .kodi/userdata) or addons (while I suspect you have removed addons from gui, there may be some remnants left - check in .kodi/addons).
If it's not it's something outside. It could be custom stuff you've installed (perhaps in /storage/.config).
You can laboriously go through the file system renaming files or directories to narrow down what is causing the crash, but it may be quicker just to switch to the clean LE install that works, and set that up as you like (check playback works after each addon installed or setting changed just in cases a change breaks it).
One doesn't seem to be getting symbols for functions, so hard to say what's happening.
The other shows openssl is repsonsible. That will be user code (not kernel) so is isn't the issue I was referring to.
Is that the on with the watchdog addon?
In either case I'd be tempted to (temporarily) disable that addon (and potentially others) to try to narrow it down.
Are both SD and HD files interlaced? (or just the SD ones)?
Do they both report hw decode?
Run "perf top" when it's laggy. Leave for a minute to settle.
If you see "vc4_atomic_commit_tail"/"clk_request_start" appearing in list (and increasing in percentage), then you have the same issue.
I don't think LE has updated Pi kernel too recently, so you'll have to wait for that to happen, and then you can test a nightly.
camelreef what you describe sounds like a problem I encountered (not with kodi) where kernel gradually consumes more and more cpu.
This was due to a leak on a linked list (we only added, never removed items), meaning searching the linked list got slower with time.
https://github.com/raspberrypi/linux/pull/4940 fixed it (not directly, but it reverted and replaced the code with the bug).
Can you play the MPEG2-SD file locally (e.g. copy to sdcard or usb stick and play from there?)
We need to determine if it's a network issue, or decode issue.
How is Pi connected to NAS? Fully wired or wireless? SMB/NFS/other?
An iperf test may be useful between Pi3 and NAS.
Are you using built in SMB/NFS/other support or OS support (e.g. mounting network drive outside of kodi then playing from there).
Ok, bug is about 3 year old, so I guess there is not a lot interest in fixing it (too bad, given it is easily reproductible).
On the bug page, someone mentions disabling MMAL acceleration avoids the issue. How do you disable this acceleration (and is it even feasible on RPi 4)?
MMAL has gone. The bug appears to be a buffer overwrite (e.g. buffer allocated is smaller than amount written).
But they tend to have fairly random symptoms - often changing something unrelated (like disabling MMAL) may make the issue appear or disappear.
Post mediainfo of a file with the issue
Are you connecting to the display through hdmi or composite (shared with headphones socket)?
Sorry for the long delay, life got in the way. I'm working on this issue, but the command getedid is not found. I'm using 9.2.8 on a RPI4. I tried adding the lines hdmi_group=1 hdmi_mode=16 to the config.txt but the device is still booting into 4k on the known good TV I'm working with. My plan is to get a good EDID from this TCL TV I have and then set it so it works on the picky Samsung unit, not sure if you think this is a good idea or not. I tried searching the edid commands for LE9 but I haven't found anything useful. Thanks for the help.
LE 9 is no longer updated. I'd suggest trying LE10 and seeing if that has the issue (and it will support getedid).
Would it be possible to add the option within the GUI to adjust this delay?
You said you fixed it with "vc4.inval_delay=0 vc4.cec_debug=0x100".
Have you fixed it with "vc4.inval_delay=<some number> vc4.cec_debug=0"
If not, there's no point adding a gui option to adjust the delay for you.
No definite ideas, but if it were me I'd try:
I would carefully check for any CEC settings in AVR menu and TV menu.
TV seems more likely to be setup correctly as it's working with a direct connection, but may have different configuration per HDMI port.
Try different hdmi ports on AVR and TV.
Unplug TV/AVR/Pi from mains and remove all hdmi connections. Leave unplugged for a minute).
Connect (just) hdmi leads from Pi to AVR and AVR to TV.
Power on TV. Then AVR. Then Pi.
I think the issue was your video was 10-bit but not HDR, which is a little unusual.
That meant the kernel didn't do a full modeset (as HDR colourspace didn't change) but did change the colour depth (which adjusts the pixel clock) which really wants a full modeset.
The test build is a stanard Matrix build with a kernel patch added to force the modeset.