Assertion 'gst_uri_is_valid (uri)' failed

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.

https://github.com/mopidy/mopidy/issues/1149 is relevant here.

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