Thanks for the log, the output looks like the remote buttons were pressed for about 2 seconds.
Stop kodi and eventlircd, then run "ir-keytable", then "ir-keytable -t" and push a button for a short time and post the output.
so long,
Hias
Thanks for the log, the output looks like the remote buttons were pressed for about 2 seconds.
Stop kodi and eventlircd, then run "ir-keytable", then "ir-keytable -t" and push a button for a short time and post the output.
so long,
Hias
Thanks a lot for reporting!
We identified the issue and reverted the breaking change. The next nightly build should be fine again.
so long,
Hias
I tested the devel version from post #33. Unfortunately, this did not solve the problem for me. The current nightly version behaves identically. Each keystroke on the remote is now repeated several times. What commands should I execute to provide a log?
Start with describing your setup (what kind of remote, IR receiver, hardware you are using) and a standard debug log (note: either use the log update function in LE settings or "pastekodi" on the command line).
so long,
Hias
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