Any way to persist HDMI edid data?

Hi guys,

my issue is that when vero4k has been rebooted while AVR and Projector are on Standby, there will be no sound and no 24p video until I reboot vero4k again while AVR and Projector are switched on. Apparently, HDMI edid info is read freshly on each boot and when AVR is on standby it will use defaults? Is there any way to persist HDMI edid data? As my devices do not change for years I do not see any reason for readong edid info on each boot.



Try powering on everything first; then Vero 4K. Then:

sudo cp /sys/class/amhdmitx/amhdmitx0/disp_cap /home/osmc/.kodi/userdata/disp_cap

Ooh, I’m glad I found this. :slight_smile:

@sam_nazarko, it seems logical to me to cache the EDID automatically: if it powers up and encounters a new EDID with different abilities, it should obviously adapt to them; but if it encounters no EDID at all, it should assume the cached version is still correct (and not change any of the settings) until it detects something.


We could do that. Concentrating on getting it to check the EDID immediately before playing some media. Vero is picking up EDID changes as they happen , it’s just Kodi that doesn’t update atm.

I think it’s correct that it should respond immediately if it detects a different EDID; the problem is what happens if there is no EDID at all, because the Vero 4K+ isn’t connected to anything - or it is, but the thing it’s connected to is switched off.

As it stands, if you reboot the Vero 4K+ with the television turned off, it changes its output resolution to 720p.

So, at the moment, the logic is something like “when rebooting, if I cannot detect an EDID that supports the current resolution, turn the resolution down”; it should be “if there actually is some kind of EDID, and it doesn’t support the current resolution, switch down”.

1 Like

This makes a lot of sense to me.
It would also get around the issue of settings->system->resolution being changed to 720p. As I understand it [edit: possibly incorrectly], even if the EDID is later read correctly, the system/GUI resolution will not revert back to 1080p or whatever it had been previously set to.

That’s right. We need a callback mechanism or a way to inform Kodi when this changes.

1 Like

Hi guys, happy to see you are taking care! Wondering why nobody else ever did complain about the current behavior - it’s really annoying. No other device (e.g. blu-ray player or PS4) behaves likes this - it just doesn’t matter in which order devices are turned on.

Looking forward to a fix!

Hi @sam_nazarko,

this worked for me, however, only for the video part (24p). As I expected it does nothing on the “no sound” issue. So my idea was to also copy the files “edid” and “aud_cap” from same location but unfortunately it had no effect. Any ideas?


we only look for disp_cap.

I wonder how Kodi does this on other platforms?

Audio shouldn’t be interpreted by Kodi based on aud_cap or autosetting sane defaults would’ve been much easier


So for audio there is no solution for the moment? I have to reboot vero 4k with AVR switched on to resolve it? No other way?

I don’t think ‘no sound’ is an EDID problem. Kodi only looks for ALSA devices and makes choices when you start to play media.

We would need some debug logs to help you with that.

Well, but aud_cap file is empty in case of vero is booting when AVR is on standby. Since I have configured pass-through for all possible audio formats I would assume that it refuses playback when output device is (wrongly) assumed to not support it?
Which logs are you asking for exactly?

Kodi never reads aud_cap. If you have a look in .kodi/temp/kodi.log you should see this, even if your hdmi cable is unplugged:

17:26:58.521 T:4080894544  NOTICE: Enumerated ALSA devices:
17:26:58.521 T:4080894544  NOTICE:     Device 1
17:26:58.521 T:4080894544  NOTICE:         m_deviceName      : default
17:26:58.521 T:4080894544  NOTICE:         m_displayName     : Default (AML-M8AUDIO Analog)
17:26:58.521 T:4080894544  NOTICE:         m_displayNameExtra: PCM
17:26:58.521 T:4080894544  NOTICE:         m_deviceType      : AE_DEVTYPE_PCM
17:26:58.521 T:4080894544  NOTICE:         m_channels        : FL,FR,UNKNOWN1,LFE,FC,BC,BL,BR,BLOC,BROC
17:26:58.521 T:4080894544  NOTICE:         m_sampleRates     : 32000,44100,48000,88200,96000,176400,192000
17:26:58.521 T:4080894544  NOTICE:         m_dataFormats     : AE_FMT_S32NE,AE_FMT_S16NE,AE_FMT_S16LE
17:26:58.521 T:4080894544  NOTICE:         m_streamTypes     : No passthrough capabilities
17:26:58.521 T:4080894544  NOTICE:     Device 2
17:26:58.521 T:4080894544  NOTICE:         m_deviceName      : hdmi:CARD=AMLM8AUDIO,DEV=0
17:26:58.521 T:4080894544  NOTICE:         m_displayName     : AML-M8AUDIO
17:26:58.521 T:4080894544  NOTICE:         m_displayNameExtra: HDMI
17:26:58.521 T:4080894544  NOTICE:         m_deviceType      : AE_DEVTYPE_HDMI
17:26:58.521 T:4080894544  NOTICE:         m_channels        : FL,FR,BL,BR,FC,LFE,SL,SR
17:26:58.521 T:4080894544  NOTICE:         m_sampleRates     : 32000,44100,48000,88200,96000,176400,192000
17:26:58.521 T:4080894544  NOTICE:         m_dataFormats     : AE_FMT_S16NE,AE_FMT_S16LE,AE_FMT_RAW

To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.

So, in summary:

  • activate the logging
  • reboot the OSMC device
  • reproduce the issue
  • upload the log set either using the Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
  • publish the provided URL from the log set upload, here

For your case, please re-boot with your AVR off then turn on AVR and display then immediately try playing a track/video which you know doesn’t produce sound. Upload logs.

Can you also confirm ‘no sound’ applies to GUI sound as well, or just passthrough formats?

find the logs here:
I also enabled debug tracing.
As you requested, the logs capture reboot while AVR is on standby, then, once up, directly playing back an .mka file with DTS HD MA audio. Issue also applies to GUI sounds, yes.

Hi grhamh, have you seen the logs I’ve provided? If you could have a look at it, I would be pleased! Thanks!

Did you take that log with the AVR on standby again?
I’d expect aud_cap to eventually populate.

Yes, as requested by grahamh. When AVR is switched on while vero4k is booting, then aud_cap is populated, yes.

I’ve been trying to reproduce what you see, specifically this

00:24:21.519 T:4038062848 INFO: CAESinkALSA - ALSA: pcm_hw.c:327:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed (-22): Invalid argument

00:24:21.520 T:4038062848 INFO: CAESinkALSA - ALSA: pcm_hw.c:1250:(snd_pcm_hw_get_chmap) Cannot read Channel Map ctl : Invalid argument

no luck so far. There is a bug in the ALSA drivers but normally it hides away unnoticed. Do you have any custom alsa.conf files, perhaps?