Am I editing the correct file?
No, use /storage/.kodi/userdata/keymaps/remote.xml.
What is the correct entry to enable the options menu?
<keymap>
<global>
<remote>
<yellow>ContextMenu</yellow>
</remote>
</global>
</keymap>I think an installation or update process of this add-on went wrong, and this can cause errors like yours.
Uninstall the YouTube add-on and reboot. If everything works fine after this, install the add-on again.
Keep the original URL and redirect the update request on your server.
Looks like something went wrong with your YouTube add-on installation. Do you have the ability to uninstall and re-install this add-on?
I don't know why, but it seems the player of Kodi uses the RAM more intensely, which then crashes if it is faulty.
I bet Plex has been used higher addressed RAM cells, and they probably worked fine. Interesting that you did the RAM test, as suggested by me, but haven't found errors. Use MemTest86, and let it run for some minutes.
Also, how do a mark it as resolved?
Hit the "Edit Topic" button over your first post (I'm using the German version, so I can't tell the exact button title), and mark the thread as solved.
Thanks for testing. Next you can try the alsa mixer this way:
amixer -c 0 set Digital 80%Is there a way to install LibreElec in headless mode?
No, but you can turn off the display by using the tvservice command on autostart.sh.
Currently, my strategy is to install Raspbian Buster Lite and install Kodi with "sudo apt-get install kodi."
Most headless LE users only do it, because they need special add-on's, which are not available for other RPi OS'es. If that's not the case for you, go the Raspbian way.
Don't forget that you will run into display package dependencies when you install Kodi on a headless Raspbian. So using a standard Raspbian and switching off the display by tvservice could be the best strategy.
Please check whether editing the volume setting of guisettings.xml (bottom of the file) makes a difference for your apps.
To my knowledge there is only one sound server available for RPi. The HiFiBerry driver feeds that sound server, and players use both components. It's on you to try different players from add-on repositories. If the sound server is the weak part, then they will have no effect.
There is an exotic Korean LE mod, optimized for audio. Currently I only see RPi 2/3 builds. Maybe they start RPi 4 support, soon.
My Ubuntu PC is only an example for issues like yours. I had exactly the same double-start issue on local audio files. It was a local buffering issue, not a stream buffering issue. I assume you have the same issue when playing an audio file locally.
Find add-on's for audio playback.
I had buffering issues on my Ubuntu PC. Using a different sound server for the same player fixed the issue.
I think it's a buffering issue, related to the audio driver. Maybe the buffering process interrupts the playback for a short time. Because you don't have the option to select a different audio driver, my advice is to contact the HiFiBerry support. They are responsible for providing a proper device driver.
You could buy this adapter to use your analogue headphones at the same time as your S/PDIF headphones.
Using the bad RPi DAC for analogue output just doesn't make sense.
Not at the moment but how is it going to be related to spdif? I do not need HDMI audio at all.
Sorry, I forgot that HiFiBerry has to be selected as LE's audio output device. Selecting PI: HDMI and Analogue or PI: Analogue will deactivate this DAC, but should activate the analogue jack of the RPi.
I assume you have been followed the official instructions. If this doesn't solve the problem, ask the HiFiBerry support. They are pretty firm.
If it turns out that it's impossible to have both outputs at the same time, then maybe an RC button switch is an option for you.
Do you have "HDMI and Analogue" activated at the LE audio settings?
Not a good idea to build an audiophile LE version for RPi's. Not just what chewitt mentioned is a problem.
Two more problems:
People often want HD audio on RPi's HDMI, but it looks like this hardware (or software implementation of audio pass-through) is too slow for native (non-PCM pass-through) HD audio (and other high speed) formats.
When trying to do the same thing with an USB DAC, then you need a real-time Linux kernel to deliver high speed audio data in time to USB. That's probably what the LE mod guys did, but it slows other tasks down.
Playing the same file several times in a row will get a different front speaker to get the center channel...
That's kind of a proof of my theory for HD audio and other formats with high data rate.
HD audio can work on LE (with better Intel NUC hardware), as proofed here: click.
