Hi All
I’m having trouble playing a HLS stream. Stream URI http://stroom.tv/varlife/lo_stroom.m3u8 returns
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:9
#EXT-X-MEDIA-SEQUENCE:6783
#EXTINF:8.333333,
lo_stroom6783.ts
#EXTINF:8.333333,
lo_stroom6784.ts
#EXTINF:8.333333,
lo_stroom6785.ts
Mopidy however (or rather Gstreamer) throws error:
(python2:9357): GStreamer-CRITICAL **: gst_element_make_from_uri: assertion ‘gst_uri_is_valid (uri)’ failed
WARNING Download of ‘lo_stroom7020.ts’ failed: Invalid URL ‘lo_stroom7020.ts’: No schema supplied. Perhaps you meant http://lo_stroom7020.ts?
INFO Unwrapping stream from URI failed: error downloading URI lo_stroom7020.ts
WARNING Problem looking up
Is this gstreamer ignoring the domain name and saying “Can’t find http lo_stroom7020.ts”? Is this a malformed m3u8 file? Funny thing is that I wrote a small python-gst application myself that plays the stream without a problem.
Any ideas?
I would guess if those were absolute paths it’d work. It looks like that’s not malformed but rather an issue with our m3u parser not supporting relative paths.
I get it - so it’s not a gstreamer error. Shall I open an issue?
For a quick fix: should I look into m3u/translator.py ?
tnx
Yes I think so.
I think something to fix up any relative paths returned needs to go around here.
I tried something like:
next_uri = uris[0]
# TODO Test streams and return first that seems to be playable
logger.debug(
'Parsed playlist (%s) and found new URI: %s', uri, next_uri)
if not urlsplit(next_uri).scheme:
next_uri = urljoin(uri, next_uri)
logger.info('Translated from relative to absolute URI %s', next_uri)
uri = next_uri
But the audio stops after a few seconds. I don’t know what is going on there:
DEBUG 2017-07-05 18:39:11,373 [20189:MainThread] mopidy.audio.gst
Got EOS (end of stream) bus message.
EDIT: OK, I do, it’s supposed to go onto the next stream in the playlist (and so on and so on, presumably). I don’t think we support this at all.
OK! So we do in fact support HLS, I got that all wrong. I think this is maybe a gstreamer issue after all. We seem to be unable to get the duration, which in turn causes our scanner to time out and then attempt to handle it as a regular playlist (which it’s not).
You can use the following to see what’s going on and compare with a working HLS stream:
$ GST_DEBUG=3 python mopidy/audio/scan.py http://stroom.tv/varlife/lo_stroom.m3u8
$ GST_DEBUG=3 python mopidy/audio/scan.py https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/gear1/prog_index.m3u8