can you post the output of

aplay -L

You can try using the correct device listed there as an argument in speaker-test

Ok apparently 384khz is out of spec for spdif devices. So lets just test by taking kodi out of the equation.

Please try stopping kodi via ssh, then using speakertest

Warning that this may blow up your AVR! I take no responsibility.

systemctl stop kodi
speaker-test -D iec958:CARD=HDAMP1,DEV=0 -c 2 -r 384000 -t sine

and see what alsa reports.

you can start kodi again by rebooting or

systemctl start kodi

EDIT:

Is this your device? Marantz CA | HD-AMP1

If so you need to make sure that you are using the USB type B plug in the back of the receiver. Spdif or the front USB won't support 384khz.

As far as I understand the "Limit sampling rate (kHz)" option is only used when using the "Fixed" Output configuration mode. Try setting this option to "Best Match" or "Optimized" if it isn't already.

see, Settings/System v16 - Official Kodi Wiki

How do you know that everything is being resampled to 192khz? Can you please post a debug log after playing a 384khz file?

I hope you like it

I'm not sure what you are wanting to do. It seems like what you are trying to do is get everything sampled at 384khz, why?

If you limit the sample rate it will resample everything above, which isn't what you want. Typically the "limit sample rate" option is to set a maximum sample rate, not a minimum.

It's more complicated than that really. It can depends on the architecture, the arm cpu type, the bootloader, the gpu, etc. This is why we have different projects for different boards.

Yes sometimes it can be as simple as changing the device tree. This is only true for amlogic hardware where the same gpu drivers. bootloader, arm cpu type, etc are used.

EDIT:

short of that you can just use the dtc tool to compile your own device tree blobs.

Quote from MidnightWatcher

Disabling OMXPLAYER and using MMAL fixes the problem. I tested 10 Dolby TrueHD 7.1 and DTS-HD 7.1 movies with "Adjust Display Refresh Rate" set to "ON START / STOP" and they all played without issue when MMAL was used. There is an issue with OMXPLAYER.

OMX player is legacy and should not be used anymore unless explicitly needed.

Quote from MidnightWatcher

Sorry, the forums had a bug reporting section stating to report them here, including video playback issues. Can you clarify the difference between a KODI bug and a LibreELEC bug? This may need to be noted in the How To notice.

Any issues that a present when using Kodi and can be seen in the Kodi debug log can be considered a Kodi bug.

Anything related to the OS itself (network, boot, shutdown, updating, backup, restore, etc) is a LibreELEC bug.

We carry a patch, LibreELEC.tv/pulseaudio-0900.03-eliminates-lags-after-bluetooth-packet-loss.patch at libreelec-8.0 · LibreELEC/LibreELEC.tv · GitHub

However as vpeter says, master is at 10.0 and a PR for 11.0 is waiting

to quote fritsch

Quote

The problem is not the GLSL but the 4x4 convolution done by Lanczos3. The GPU is too slow to process content > 1920 with this HQ scaling method, which is - from the logs - the same problem with your 3840 file.

Red Overlay on TV with Libreelec if i change to Render Method Basic Shader

you probably need the correct dtb.img

sounds like the typically addons27.db issue to me

No. Linux does not support running android apps. If you want to do that you should probably just run android.

Quote from Mario77

Do you mean the run-fan.py if renamed to autoexec.py will run on startup?

yes, if it's located in that specific directory

Or you could just name it

/storage/.kodi/userdata/autoexec.py

then kodi will automatically start it when kodi starts.

something along the lines of (I don't have the device with me to test)

echo 0 > /sys/class/led/led0/brightness

Do you have libwidevine installed? (I think that's needed)