SVT Play livestream spontaneously quits after 1 second if played on LibreElec

    Describe the bug

    Using kodi-svtplay addon on LibreElec, when streaming live TV, the videostream plays for approx. 1 second before spontaneously quitting.

    How to reproduce

    Steps to reproduce the behavior:

    1. Install the SVT Play addon (Addons - Install from repo - Kodi Addon Repo - Video addons - SVT Play)
    2. Open the addon.
    3. Go to Channels and pick any channel.
    4. The video stream will play for only one second before quitting.

    Information

    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.

    Edited once, last by nosen: Added info about the bug beibg present on OSMC (November 20, 2025 at 5:57 PM).

    This could be the cause of the issue:

    Code
    2025-11-01 10:48:10.479 T:1208     info <general>: CDVDVideoCodecDRMPRIME::Open - using decoder V4L2 mem2mem H.264 decoder wrapper
2025-11-01 10:48:10.479 T:1208    error <general>: ffmpeg[0x212e50a0]: [h264_v4l2m2m] Could not find a valid device
2025-11-01 10:48:10.479 T:1208    error <general>: ffmpeg[0x212e50a0]: [h264_v4l2m2m] can't configure decoder
...
2025-11-01 10:48:10.540 T:1214    error <general>: ffmpeg[0x209fd8f0]: [deinterlace_v4l2m2m] Could not find a valid device
2025-11-01 10:48:10.540 T:1214    error <general>: ffmpeg[0x209fd8f0]: [Parsed_deinterlace_v4l2m2m_0] Failed to configure output pad on Parsed_deinterlace_v4l2m2m_0
2025-11-01 10:48:10.540 T:1214    error <general>: CDVDVideoCodecDRMPRIME::FilterOpen - avfilter_graph_config:  Invalid argument (-22)

    I'm not an expert in reading streaming service logs (and different services will behave differently) but it looks like audio and video are separate streams, and everything goes through a normal looking process of obtaining stream manifestsa and then selecting audio and video streams. The audio stream looks to be selected, but then the video stream switches from SD (448x252@50) to HD (1080p@50) and then the stream stalls.

    There are quite a lot of streaming add-ons installed so I would be interested to see logs from a current LE13 nightly that has only the SVT play and inputstream.adaptive add-ons installed. I'm not expecting anything to be different, but it will remove some noise from the log. I don't see any 'errors' that would e.g. indicate Python issues or something that traces back to the underlying OS. IMHO if there's a difference between the add-on under LE and the add-on the author tested on Ubuntu it's more likely to be add-on or i.a configuration and not the OS environment.

    NB: The stream is H264 and RPi5 does not have H264 hardware decode or hardware deinterlacing so the v4l2_m2m errors in the log that Da Flex has seized upon are nothing more than ffmpeg correctly failing to find hardware decode and deinterlace /dev/video nodes that don't exist and failing back to use software capabilities. All normal and expected on an RPi5 device.

    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...

    Recently HiassofT added libx264 to the external ffmpeg I wonder if the same thing has to be done within Kodi or if that is even possible with DRM Prime

    It's not transcoding though since the source is already h264 so I wonder if it something else. nosen if you enabled subtitles in the plugin does turning them off help?

    The ffmpeg version used with Kodi supports software decoded H264 on RPi5 without issues and transcoding is not relevant to the problem. Our usersbase is ~80% RPi boards and if there were fundamental issues with H264 we'd have a thousand forum posts on the topic.

    Quote from nosen

    Question: I think I have inputstream libraries installed from both slyguy and kodi. Can that cause conflicts? Or am I overthinking it...

    There is no inputstream addon involved and therefore no helper required. The HLS stream is directly played by kodi.

    Hint: after disabling the geo-blocked content in SVT addon settings everyone is able to test. Works on my personal LE12.2 Generic development image.

    Quote from mglae

    Hint: after disabling the geo-blocked content in SVT addon settings everyone is able to test. Works on my personal LE12.2 Generic development image.

    Good hint, the non-geoblocked content works fine here on LE12.2.1 / RPi5 as well.

    so long,

    Hias

    Quote from nosen

    Clean image of 13.0 20251117 nightly. Interestingly, the glitch is not present on this version.

    Now start adding back add-ons and config from the other install piece-by-piece until you either end up with a fully configured system, or you find the add-on or config step that breaks things.

    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.

    LE12.2 is a fork of the LE13 codebase from a couple of months back retrofitted with K21 not K22, and notably with the same ffmpeg version used in both. So if you want to play 'spot the difference' there's more in-common between the LE12.2 and LE13 than there is between LE12.0 and LE12.2 (and that difference is too large to spot anything). Combine that with the add-on working for multiple users with non geoblocked content on both releases and my suspicions are towards add-on config or something environmental not an issue with the base OS; and hence the suggestion to test that theory.

    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.

    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.