Not really sure about the Readrate message - I've never seen that here. Might be worth to check journal/dmesg if there's some actual problem with the USB drive.
BTW: When posting logs from the console please use the "pastekodi" script. This will also include journal/dmesg which can contain very important info. And also please don't use a mouse, that spams the kodi log with lots of useless pointer move messages and it's very hard to find the actually relevant information.
so long,
Hias
RPi4 with 1GB is quite short on memory, if you experience Kodi crashes when navigating through pictures or movie library you may need to tweak GPU and CMA memory - search the forum, this has been asked (and answered) a couple times before.
so long,
Hias
From the log it seems you have "Adjust display refresh rate" set to off. Please make sure it's enabled ("On start/stop" is in general a good choice) and your display whitelist is setup properly.
"snd_pcm_writei(-32) Broken pipe" means audio underrun which more likely is caused by A/V sync issues if the display is not running at the same refresh rate as the video.
I can't comment on the dvd menu change, please open a separate thread (or issue on kodi github) about that.
so long,
Hias
A new testbuild with improvements for HD audio dropout issues is available here: RE: Nightly builds Rpi4 Audio passthrough TrueHD/Master HD not working (huge stutter) anymore - please continue discussion in the linked thread so posts aren't scattered around too much.
so long,
Hias
Could you please test with this build: LibreELEC-RPi4.arm-9.80-devel-20210106194320-356965b.tar
It contains additional hdmi audio DMA patches by popcornmix (bumping audio DMA priority to max).
Source code of that build is here GitHub - HiassofT/LibreELEC.tv at le10-test
so long,
Hias
The fix in the testbuild is included in this PR: linux (RPi): update to 5.10.4 by HiassofT · Pull Request #4871 · LibreELEC/LibreELEC.tv · GitHub
The problem is that H264 hardware decoding consumes quite a lot of RAM bandwidth and that results in HDMI audio FIFO underrun as audio DMA gets delayed because RAM is busy.
The kernel patch included in the testbuild (and the PR) increases the memory bandwidth for audio DMA which helps a lot, but it looks like a bit more tweaking is needed.
Unfortunately neither kodi nor kernel log will show anything if or when that happened.
As a workaround you can also disable hardware decoding (in player->video settings), software-decoded H264 videos (which was the default in nighty builds until a few weeks ago) don't suffer from the audio dropout issue.
so long,
Hias
Thanks for the feedback, good to hear the fix is working!
I'll send the fix upstream (as it's a genuine linux kernel bug) and also create a LibreELEC PR with it so it should be in master soon.
so long,
Hias
Could you please test if this build fixes the issue? LibreELEC-Generic.x86_64-9.80-devel-20210104155843-30e9b8c.tar
so long,
Hias
Thanks a lot for the logs, I could now reproduce the issue locally.
Failed scancode decoding was a red herring, the issue seems to be caused by wrong timeout handling which results in the key_up event before the last scancode.
I already have an idea what might be causing that, will do some tests and then report back.
so long,
Hias
Meh, decoding seems to be fine again 
Please try to catch output where you get a "key_up" event as suggested in my last post RE: [Intel] Nightly build...problem with mce remote
so long,
Hias
Hint: it might be better if you test with kodi and eventlircd stopped, then you'll also see the key events. If you see a "key_up" line in the middle of the output you'll know that things have failed - and ir-keytable/ir-ctl outputs should contain something useful for me.
so long,
Hias
Thanks again for testing. The stray signals could be harmless (and I also have no explanation why earlier builds would behave differently), but they looked a bit too frequent for my taste.
Unfortunately the scancode output is fine again... Could you test it again, this time press a button for 5 seconds (that'll give a higher chance we catch the issue).
so long,
Hias
Unfortunately there didn't seem to be any scancode decode errors in the nightly test. Could you repeat that one?
I've noticed though that the IR receiver seems to be picking up quite some noise (the "+100 timeout # ..." lines from ir-ctl -r). Noise / stray signals from fluorescent lights etc can also harm IR decoding. Please also try running "ir-ctl -r" (without output redirect) and check if covering the IR sensor, turning off lights, closing the curtain etc reduce the amount of those lines.
so long,
Hias
Thanks a lot for testing! It looks like sometimes scancodes aren't properly decoded. Usually IR signals / scancodes repeat in about 100ms intervals, if no scancode is received within that time it's interpreted as button release.
Can you please do another test, both with milhouse and nightly builds:
Open two shells, in one shell run "ir-keytable -t" in the other one "ir-ctl -r > ir.txt", then press a button for about 2 seconds. After that stop "ir-ctl" with ctrl-c, it should have created an ir.txt file with a large bunch of numbers. Please post both that file and the output you got from ir-keytable -t
I'm suspecting a recent kernel change (switching from ns to us timing values) might be responsible but I can't reproduce that locally with my IR hardware - it might be specific to the nuvoton cir. The ir-ctl raw signal values should hopefully give some more hints.
so long,
Hias
Can you redo the tests and push the button a bit longer, one second or so? Would be good to see more "lirc scancode" lines (at least 5, better 10).
so long,
Hias
Please post the outputs of ir-keytable -t with kodi and eventlircd stopped. Push a button for about half a second, do that both on the milhouse and the latest nightly build.
so long,
Hias
hello! ive installed nightly with date 2020-12-30 and skipping works great, however I get weird artifacts on the side of my tv (Sony 55" A85 4K UHD OLED Smart TV KD55A85), it appears both in menu and while playing video.
This is a known issue in the video driver, see eg here RE: LibreELEC display rolled around by one pixel
so long,
Hias
