I think you are just very unfortunate. I have used many different raspberry pis and sd cards for 10+ years and I have had this happen only once in all that time. I have heard an argument that sd cards in raspberry pis are actually not ideal, because the read/write of the pi will wear out the sd cards' internal nand flash.
If you want to boot from a more robust media, there is a config that lets you use an external ssd. Nvme should be more suited for the r/w load.
Thanks! I got it working!
First, I did a non-persistent test by running
systemctl stop kodi
kmstest -c HDMI-A-1 -P "Broadcast RGB=1" < /dev/null
systemctl start kodiWhen I saw that it worked, I made it persistent with this command:
echo 'kmstest -c HDMI-A-1 -P "Broadcast RGB=1" < /dev/null' >> /storage/.config/autostart.sh
systemctl restart kodiI want to force full RGB (0-255) HDMI output.
This is because my TV (a 2016 Samsung KS7000) thinks the RPi5 is a PC, so it expects full RGB, and skips parts of a full EDID handshake. The Pi does not receive a full EDID, so it falls back on limited range. This mismatch causes lifted blacks and muted highlights, resulting in a washed-out picture. I tried configuring the TV for limited range, but that only persisted until I changed the source back and forth, then the mismatch came back (it's a glitchy and bad TV set honestly).
Is there some way to configure the config files to force full RGB (0-255)?
Ah, that looks like the solution. Thanks!
Starting with nightly version 2025-12-13, I don't get HDMI output after clean installs. LibreELEC-RPi5.aarch64-13.0-nightly-20251210-dd92255.img.gz is the last version that works out of the box. All versions later than that do not output any HDMI. I think Kodi is still running, because I can ping the Pi, and I notice that the Pi reboots after first power on (after resizing the partition, i guess, I'm not certain because I don't have video output).
My setup is a RPi5 connected via HDMI0 (the port closest to the USB-C power port) using an original Raspberry Pi Micro-HDMI to full size HDMI cable. It is connected to a 2016 Samsung KS7000 TV. I suspect this older TV might exhibit this quirky behavior: it may skip EDID handshakes with PCs (it identifies the Raspberry Pi as a PC), but I have not confirmed this yet. I have noticed that if the source is configured as a PC, the TV applies a picture profile that is very restrictive: It disables a lot of the picture settings and forces full HDMI color range, so that is why I suspect the TV to be weird about PC inputs in general.
Sidenote: I am currently trying to find some config.txt option that restores HDMI output but it's cumbersome, since SSH is disabled and I don't know if I can enable it without seeing the GUI. This leaves me with the only option of pulling out the RPi5's power cable, removing the SD card and putting it into my laptop, tweaking the config.txt file, putting the SD card back into the RPi5 and reinserting the power cable. If there is a way to enable SSH by configuring the SD card somehow, I'd love to know.
Whoa, a couple of things:
First, thanks for letting me know that the nightly version is stable enough to daily-drive. That piece of information puts the situation in a new light. I didn't consider it to be a viable workaround. I don't think I came across as obsessing over the stable label though.
Second, I'm not the only user. There has been another LE user in this very thread who confirmed the issue.
Third, I didn't try to pass the buck. I assumed (correctly, it turned out) that you had misunderstood the issue (despite having clear step-by-step instructions for how to reproduce the bug). When I figured out you hadn't understood the issue, I asked for your confirmation. I thought you might direct me to do another test, now that you had a better grasp of the problem.
I assure you that I act in good faith and want to help improve Kodi and LE for everyone. If that's not an interesting proposition for you, we can stop trying to fix this bug. I want to keep going, but I need your help to continue.
As for right now, I'll try switching to nightly and piece by piece install and configure until the bug comes back, if it comes back at all. Does that sound like a good plan to you?
That is puzzling, since I can play live TV on 13.0 nightly but not 12.2.1. Maybe the livestream format that SVT is serving is a little unorthodox or "out of spec" somehow, in a way that some players tolerate but stalls others players?
You understand me correctly, but I don't want to switch my daily driver to the nightly version for two reasons: One, I want to use the stable branch so that I don't have to deal with stability problems, and two, I think it's useful to keep debugging this so we may identify the bug, and stop it from popping up again later.
I see your reasoning, but I want to be crystal clear: the bug only manifests on a small subsection of content, namely live tv i.e. the same thing you'd see on the regular terrestial broadcast. I don't think that's available outside of Sweden (test this by following the instructions in my original post). All VODs work for me on all versions, they play like expected and do not stall.
Still want me to test? I will humor you if that's the case.
That seems unnecessary, since we have already established that the bug is present on a clean image of 12.2.1 but not in the nightly release, no? The bug has to be somewhere in the base system on 12.2.1, and not related to any other addons. I can't see how any other addons could be the culprit here.
Here is a log file from streaming on a clean image of 13.0 20251117 nightly. Interestingly, the glitch is not present on this version.
Here is a log file from doing the glitch on a clean image of 12.2.1, with only the SVT Play addon installed. I will try 13.0 nightly shortly.
Thanks, I'll try a separate SD card loaded with LE13 nightly and only SVT Play and inputstream.adaptive addons installed. I'm at work so it will have to wait for about 10 hours though. I will report back if the behavior changed, and provide a cleaner log file.
Question: I think I have inputstream libraries installed from both slyguy and kodi. Can that cause conflicts? Or am I overthinking it...
Using kodi-svtplay addon on LibreElec, when streaming live TV, the videostream plays for approx. 1 second before spontaneously quitting.
Steps to reproduce the behavior:
This is only reproducible on LibreElec Kodi. Another user reports this bug on OSMC. Using Kodi 21.3 on Ubuntu does not spontaneously quit.
Let me know if SVT Play is IP geolocked to Sweden.
Log file available in the github issue thread linked above.