2021-01-08, 03:10
Hello everyone,
I am developing an add-on as a counterpart to an Android app, Web Video Caster, which is a browser that filters media in webpages and allows you to "cast" them to other devices, such as smart TV's and other Android devices with a "Receiver" application (made by the same developer). Kodi's built-in DLNA/uPnP worked with it, though not in the best fashion, so I contacted the application's developer and he's helping me with the specifics needed to interact with his app, but I've stumbled upon an issue.
The add-on simply takes the URL of the video, some headers and a subtitle link if any is given, parses them and calls the Kodi Player to run a ListItem that has the details necessary for the video. As far as I researched and I'm aware of, it should be using the "inputstream.ffmpeg" built-in add-on as I'm not supplying anything custom. Anyway, so far, so good. It even works in a better fashion than the DLNA method, which was a 50% hit or miss, in my experience. However, on some occasions, though not extremely often, maybe once every 10 mins or so, the video stutters, green artefacts appear, and it loses like a second or two worth of frames before going back to normal, subtitles then getting delayed. Audio and video return to normal, though.
Let me also mention that so far this ocurred only with (and was mostly only tested with) HLS m3u8 videos.
So I battled this for a couple of days and looked into options and plenty of threads. I tried using the "inputstream.adaptive" add-on, and while that works for some videos, it doesn't for others, although they are all m3u8. The videos I'm targeting are from a streaming site, although it could literally be anything as the application that "casts" them is a browser in its own, able to navigate anywhere and scrape virtually any webpage.
In any case, here's what I tried in regards to inputstream.adaptive(with the lines below uncommented, of course):
But that didn't make too much of a difference. It might have fixed some videos, but others wouldn't work at all now. I read that FFMPEG supports more formats than the inputstream.adaptive addon, so I guess it also comes down to that, in a way. So I reverted to the inputstream.ffmpeg add-on, and since I needed more info I turned to the logs, and this snippet caught my eye:
It looks like the connection for the stream could not be kept alive so a new one had to be established, which would explain the discontinuation in the video. Might have something to do with TLS. I am honestly a bit overwhelmed. This behavior occurs on a Raspberry Pi 3B running LibreElec 9.26 and Kodi 18.9 and also in Windows 10 running Kodi 18.9. So it's not a platform specific issue.
Here is the log from the Windows 10 machine where I replicated the issue after a reboot. The log is identical on the RPi from this aspect, but if needed, I can gather one from that device as well.
Please let me know if I left out any information that might be needed or might help, and thank you in advance for any idea or advice you might have!
I am developing an add-on as a counterpart to an Android app, Web Video Caster, which is a browser that filters media in webpages and allows you to "cast" them to other devices, such as smart TV's and other Android devices with a "Receiver" application (made by the same developer). Kodi's built-in DLNA/uPnP worked with it, though not in the best fashion, so I contacted the application's developer and he's helping me with the specifics needed to interact with his app, but I've stumbled upon an issue.
The add-on simply takes the URL of the video, some headers and a subtitle link if any is given, parses them and calls the Kodi Player to run a ListItem that has the details necessary for the video. As far as I researched and I'm aware of, it should be using the "inputstream.ffmpeg" built-in add-on as I'm not supplying anything custom. Anyway, so far, so good. It even works in a better fashion than the DLNA method, which was a 50% hit or miss, in my experience. However, on some occasions, though not extremely often, maybe once every 10 mins or so, the video stutters, green artefacts appear, and it loses like a second or two worth of frames before going back to normal, subtitles then getting delayed. Audio and video return to normal, though.
Let me also mention that so far this ocurred only with (and was mostly only tested with) HLS m3u8 videos.
So I battled this for a couple of days and looked into options and plenty of threads. I tried using the "inputstream.adaptive" add-on, and while that works for some videos, it doesn't for others, although they are all m3u8. The videos I'm targeting are from a streaming site, although it could literally be anything as the application that "casts" them is a browser in its own, able to navigate anywhere and scrape virtually any webpage.
In any case, here's what I tried in regards to inputstream.adaptive(with the lines below uncommented, of course):
python:
li = xbmcgui.ListItem("Casted Video", path=video_url)
li.setIsFolder(False)
li.setProperty("isPlayable", "true")
# li.setMimeType(data['mimeType'])
# inputstream_property = "inputstreamaddon" if self.kodi_version < 19 else "inputstream"
# li.setProperty(inputstream_property, "inputstream.adaptive")
# li.setProperty('inputstream.adaptive.manifest_type', 'hls')
# li.setProperty('inputstream.adaptive.stream_headers', header_str)
li.setSubtitles(subtitle_list)
xbmc.Player().play(li.getPath(), li)
But that didn't make too much of a difference. It might have fixed some videos, but others wouldn't work at all now. I read that FFMPEG supports more formats than the inputstream.adaptive addon, so I guess it also comes down to that, in a way. So I reverted to the inputstream.ffmpeg add-on, and since I needed more info I turned to the logs, and this snippet caught my eye:
html:
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [hls,applehttp] HLS request for url 'https://5nr6of.cfeucdn.com/secip/34055/fAwkOsWyJXBVxO_9ffJQrg/ODYuMTIxLjE1MS43MQ/1610084961/hls-vod-s02/flv/api/files/videos/2016/08/21/1471728030f613a.mp666/Frag-6-v1-a1', offset 0, playlist 0
2021-01-08 02:22:48.140 T:10936 INFO: ffmpeg[2AB8]: [https] Opening 'https://5nr6of.cfeucdn.com/secip/34055/fAwkOsWyJXBVxO_9ffJQrg/ODYuMTIxLjE1MS43MQ/1610084961/hls-vod-s02/flv/api/files/videos/2016/08/21/1471728030f613a.mp666/Frag-6-v1-a1' for reading
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] request: GET /secip/34055/fAwkOsWyJXBVxO_9ffJQrg/ODYuMTIxLjE1MS43MQ/1610084961/hls-vod-s02/flv/api/files/videos/2016/08/21/1471728030f613a.mp666/Frag-6-v1-a1 HTTP/1.1
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] User-Agent: Kodi/18.9 (Windows NT 10.0.18363; Win64; x64) App_Bitness/64 Version/18.9-(18.9.0)-Git:20201023-0655c2c718
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] Accept: */*
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] Host: 5nr6of.cfeucdn.com
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] Icy-MetaData: 1
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] Connection: keep-alive
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https] Referer: https://hqq.tv/player/embed_player.php?v...1217261258
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [https]
2021-01-08 02:22:48.140 T:10936 ERROR: ffmpeg[2AB8]: [tls] error:00000000:lib(0):func(0):reason(0)
2021-01-08 02:22:48.140 T:10936 DEBUG: ffmpeg[2AB8]: [AVIOContext] Statistics: 1971448 bytes read, 0 seeks
2021-01-08 02:22:48.142 T:10936 DEBUG: ffmpeg[2AB8]: [hls,applehttp] keepalive request failed for 'https://5nr6of.cfeucdn.com/secip/34055/fAwkOsWyJXBVxO_9ffJQrg/ODYuMTIxLjE1MS43MQ/1610084961/hls-vod-s02/flv/api/files/videos/2016/08/21/1471728030f613a.mp666/Frag-6-v1-a1', retrying with new connection: I/O error
2021-01-08 02:22:48.142 T:10936 INFO: ffmpeg[2AB8]: [hls,applehttp] Opening 'https://5nr6of.cfeucdn.com/secip/34055/fAwkOsWyJXBVxO_9ffJQrg/ODYuMTIxLjE1MS43MQ/1610084961/hls-vod-s02/flv/api/files/videos/2016/08/21/1471728030f613a.mp666/Frag-6-v1-a1' for reading
It looks like the connection for the stream could not be kept alive so a new one had to be established, which would explain the discontinuation in the video. Might have something to do with TLS. I am honestly a bit overwhelmed. This behavior occurs on a Raspberry Pi 3B running LibreElec 9.26 and Kodi 18.9 and also in Windows 10 running Kodi 18.9. So it's not a platform specific issue.
Here is the log from the Windows 10 machine where I replicated the issue after a reboot. The log is identical on the RPi from this aspect, but if needed, I can gather one from that device as well.
Please let me know if I left out any information that might be needed or might help, and thank you in advance for any idea or advice you might have!