If I see well you are using skin.confluence-extended, please try with the default skin, just out of curiosity.
It did not help. It helps to turn off the next parameter - Settings - Player - Allow hardware acceleration amcodec - off. But then it slows down a lot.
Does the box do a full reboot or does only Kodi restart?
If it’s only Kodi, then you should have a crashlog.
If the whole box reboots, then I fear that the only real way we may get somewhere is with a UART log, which could indicate the position of the kernel oops. None of us have a S905D device, and on all devices we have, we do not have this problem.
The box do a full reboot
How can I obtain the UART log?
I have a USB-UART adapter, and I am using it with VIM3. But I don’t know how to connect it to KI Pro. Thanks again!
There are several methods.
- The simplest method we could try to start with is to SSH into the device, run
journalctl -kf, which will start dumping all dmesg output into the SSH session. Maybe this will allow us to catch thekernel oopsbefore it restarts. - You can use the CoreELEC Team SDIO Debug Board
- Most boxes have UART pads on the PCB. You can open it and connect your UART adapter to those pads (you only need TX,RX,GND, don’t connect VCC)
Thanks. I started with a simple method, but it didn’t give me anything interesting.
CoreELEC (official): 19.2-Matrix_rc2 (Amlogic-ng.arm)
CO:~ # journalctl -kf
– Journal begins at Tue 2021-02-02 17:29:47 EET. –
Jun 23 20:06:32 CO kernel: snd_spdif_dai: set normal 512 fs /4 fs
Jun 23 20:06:33 CO kernel: snd_spdif_dai: aiu 958 playback enable
Jun 23 20:06:33 CO kernel: snd_spdif_dai: aiu 958 playback disable
Jun 23 20:06:33 CO kernel: snd_spdif_dai: set normal 512 fs /4 fs
Jun 23 20:06:33 CO kernel: snd_spdif_dai: aiu 958 playback enable
Jun 23 20:06:33 CO kernel: snd_spdif_dai: aiu 958 playback disable
Jun 23 20:06:33 CO kernel: snd_spdif_dai: set normal 512 fs /4 fs
Jun 23 20:06:34 CO kernel: snd_spdif_dai: aiu 958 playback enable
Jun 23 20:06:34 CO kernel: snd_spdif_dai: aiu 958 playback disable
Jun 23 20:06:34 CO kernel: snd_spdif_dai: set normal 512 fs /4 fs
Jun 23 20:07:15 CO kernel: audio_dsp: buf=0
Jun 23 20:07:15 CO kernel: audio_dsp: IEC958_mode_raw=0
—REBOOT Box—
Yeah, sadly this doesn’t help.
I’d expect to see an output with errors.
Have you tried a different power supply? Sometimes bad power supply can cause weird issues.
Other than that, we need to follow options 2 or 3, as 1 didn’t give us any useful results.
I have changed power supplies.
I’m trying to order SDIO Debug Board.
I am already wondering.
Received the CoreELEC Team SDIO Debug Board, connected it.
Result - https://drive.google.com/file/d/1CCuvCnpaZBta8Y7iN7WkCSEXpl1coGj3/view?usp=sharing
Nothing 
Please set correlec to
coreelec='nopkmute'
in the config.ini file, reboot and then see if you get proper output in UART console.
Ok.
Here is the new result -
CI:~ # journalctl -kf
[ 64.525290@1] fb: mem_free_work, free memory: addr:800000
WARNING: Unimplemented Sip Call: 0x8200004a
WARNING: Unimplemented Sip Call: 0x8200004a
[ 72.582388@3] hdmitx: hw: set audio
[ 72.582432@3] hdmitx: hw: hdmitx tx_aud_src = 0, audio_param->channel_num = 1, hdev->aud_output_ch = 0
[ 72.589606@3] hdmitx: fs = 2, cd = 4, tmds_clk = 148500
[ 72.594727@3] hdmitx: hw: aud_n_para = 6272
[ 72.598897@3] hdmitx: hw: set channel status
[ 72.603183@3] hdmitx: audio: Audio Type: PCM
[ 72.607330@3] hdmitx: audio: set audio param
WARNING: Unimplemented Sip Call: 0x8200004a
WARNING: Unimplemented Sip Call: 0x8200004a
WARNING: Unimplemented Sip Call: 0x8200004a
[ 84.056941@3] VID: VD1 off
[ 84.061874@2] The fw has been loaded.
[ 84.061920@2] vdec_init, dev_name:ammvdec_h265, vdec_type=VDEC_TYPE_FRAME_BLOCK
[ 84.077556@3] [LOCAL], the fw (hevc_mmu) will be loaded.
[ 84.077815@3] ppmgr local_init
[ 84.080481@3] di_receiver_event_fun: vframe provider reg ppmgr
[ 84.087749@3] DI: reg f
[ 84.088717@1] ppmgr local_init
[ 84.093497@2] vdec->port_flag=0x102, port_flag=0x10b
[ 84.166286@1] snd_spdif_dai: enterd aml_spdif_play,set_clock:5,sample_rate=4
[ 84.167724@1] hdmitx: hw: set audio
[ 84.171744@1] DI bypass all 3840x2160-0x501000.
[ 84.171745@1] hdmitx: hw: hdmitx tx_aud_src = 0, audio_param->channel_num = 1, hdev->aud_out
—REBOOT Box—
One more attempt -
CI:~ # dmesg|paste
http://ix.io/3sXn
CI:~ #
WARNING: Unimplemented Sip Call: 0x8200004a
WARNING: Unimplemented Sip Call: 0x8200004a
[ 93.896910@1] hdmitx: hw: set audio
[ 93.896957@1] hdmitx: hw: hdmitx tx_aud_src = 0, audio_param->channel_num = 1, hdev->aud_output_ch = 0
[ 93.904216@1] hdmitx: fs = 2, cd = 4, tmds_clk = 148500
[ 93.909391@1] hdmitx: hw: aud_n_para = 6272
[ 93.913479@1] hdmitx: hw: set channel status
[ 93.917676@1] hdmitx: audio: Audio Type: PCM
[ 93.921865@1] hdmitx: audio: set audio param
[ 94.060143@0] VID: VD1 off
[ 94.063559@0] The fw has been loaded.
[ 94.063613@0] vdec_init, dev_name:ammvdec_h265, vdec_type=VDEC_TYPE_FRAME_BLOCK
[ 94.079814@3] [LOCAL], the fw (hevc_mmu) will be loaded.
[ 94.080121@3] ppmgr local_init
[ 94.082651@3] di_receiver_event_fun: vframe provider reg ppmgr
[ 94.089911@2] DI: reg f
[ 94.091715@2] ppmgr local_init
[ 94.096368@1] vdec->port_flag=0x102, port_flag=0x10b
[ 94.164560@1] DI bypass all 3840x2160-0x501000.
—REBOOT Box—
Is this the UART log?
Yes exactly
What is the Android version installed on your box?
Android version 7.1.1
CoreELEC 19.2-Matrix_rc2 instaled to eMMC
Judging by the WARNING: Unimplemented Sip Call: 0x8200004a messages, it seems that your Android image uses an old bootloader.
You’ll need to find and flash a newer image, with which there will not be any more such errors and see if the problem still occurs.
Unfortunately, there were no newer versions Android for this box.
You could try a custom ROM, or upgrade your device. With the problematic bootloader on your box we can’t do much to help. HDR10+ most definitely works with S905D and S905X devices, using the same CE version, so it is something on your side that is causing the problem.