The things you mentioned are all normal and occur on my system with working audio.
Another display would be a useful test.
Also if your current display has another hdmi port try that.
The things you mentioned are all normal and occur on my system with working audio.
Another display would be a useful test.
Also if your current display has another hdmi port try that.
I don't see any audio errors in log (it looks much like mine).
Can you confirm if any local setting are causing the issue? Simplest way is to ssh in and:
You should now have kodi running with default settings. Any audio from navigating gui or playing a video?
If you want to return to your old settings then:
I have noticed that the latest nightly does have the same kernel oops as in the original log. So favourite is the popcornmix fix scheduled for linux 6.1, maybe it has not been back ported to 6.0.5 properly.
You are correct. I've just checked and the fix from 6.1 is missing from 6.0 tree. I've cherry-picked it to rpi-6.0.y, so should appear next time LibreELEC bumps their kernel version (probably best to wait for confirmation here, as that's not an automatic process).
I believe a backport of the VC-1 patches are in current LE. e.g. see https://github.com/LibreELEC/LibreELEC.tv/pull/6538
I think errors like "mmco: unref short failure" are common when source is live TV (where there may be errors in stream, or it may start from a non-I frame). I don't think it fatal for playback.
But otherwise I don't know much about non-pi kodi, especially the audio drivers (which sounds like where the issue is).
Kodi is left running all the time and the LG is put into standby with the remote. After a while, the TV is restarted and the message no video signal appears.
Looks like you are using the Nightly/kodi 20 build. I assume that stable/matrix build works okay?
The error relates to i2c, and may be fixed by this.
This weekend I'm visiting my mother, I can test two more displays there.
That would be useful. If it works on both of those, then it suggests your original TVs have an issue we don't cope well with.
If they also fail, then it's not the TV, but something related to the pi (what's on sdcard, or pi hardware or hdmi cable).
Is there any type of file that makes them occur more frequently?
Finding a use case that can reliably reproduce the issue without too much waiting will make debugging easier.
I’m using the original cable included with the RPI. Tried to include”hdmi_force_hotplug=1“ in config.txt, but it doesn’t solve the problem.
In general, hdmi_* lines in config.txt apply to deprecated firmware display driver.
A more suitable line would be to add:
to the end of cmdline.txt (on the same line).
For testing you can also try switching to the fkms driver. In /flash/distroconfig.txt change:
to
Can you confirm that you have two displays that behave this way?
One display that doesn't play nicely would be surprising, two seems very unlikely and may suggest an issue elsewhere (but your issue is not affecting the vast majority of users).
Can you confirm you don't have a case with hdmi extenders?
well, I've updated to 10.0.3 and this problem is instantly back. Do we still need to edit the cmdline.txt in 10.0.3 or was this supposed to be resolved permanently? Thanks!
The command line will always be required if you have equipment that is affected by this issue.
It looks like this should be supported.
HiassofT can you think of a reason for sink to fail to open?
BTW. Maybe it could be useful for developers to have the edid files from not-working configurations to analyze.
If i am not mistaken, the edid create saves the edid-HDMI-A-1.bin file to /storage/.config/firmware/edid/ folder (and also edid-HDMI-A-2.bin for devices with two HDMI ports like RPi 4B etc.).
And it's possible to look what's there with:
edid-decode /storage/.config/firmware/edid/edid-HDMI-A-1.bin
I'm happy to receive edid files that cause a problem, but I think most issues are due to a lack of edid file.
If the hdmi cable is missing hotplug, SCL or SDA lines (which cheap cables can do to save costs),
then we can't read the edid.
This issue can also be caused by the Argon One case which does a similar thing with cable extenders.
Less common is a fault on display (worth trying different hdmi inputs, or a different display).
You can run:
on a booted system (ssh in if display is blank). If you get lots of info about modes supported, then you have an edid.
If you get an error, then we can't read the edid, and the only solution (apart from fixing the underlying issue) is editing config files.
I think the simplest change to get a picture without an edid would be to add to end of cmdline.txt:
(or some other resolution you know the display supports).
But note, without an edid, kodi won't know the range of refresh rates supported (for "adjust display refresh rate to match video"), and CEC and audio passthrough are unlikely to work fully.
Basically I just want to have the best video and audio possible, as currently with using one HDMI port I am limited to the bandwidth of ARC (DTS, DD, 2.0 PCM). Today I used "getedid create" for the first time which ensures that the RPI also outputs video when the TV is turned on afterwards/later. Couldn't a custom EDID file be created which combines the max video settings of the TV and the max audio settings of the AVR? At least I imagine that the TV receives the correct video but cannot play the audio signal and the AVR receives the HD audio although the picture might not be correctly displayed as my AVR is not HDR compatible (only 4k) which I wouldn't care about.
ARC doesn't support HD audio formats.
(Note: there is a HDMI2.1 eARC standard that does, but it would need to be supported by TV and AVR, and I suspect they don't).
Assuming you are connected as:
Pi<---hdmi--->TV<---ARC--->AVR
then fudging the EDID won't help. The ARC connection can't support it.
If you can connect:
Pi<---hdmi--->AVR<---hdmi--->TV
Then HD audio should work.
Using the second hdmi connector should be possible.
If you find any way of provoking the glitch more frequently (e.g. navigating between two specific screens) that would be helpful.
It's pretty much impossible to debug a glitch that occurs once a week.
Not sure I see the linked issues as being too similar.
The commit indicated as fixing the ubuntu issue has been in our 5.15 tree since Nov 2021, so will be in these builds.