I am running Mopidy 3.4.1 on a Raspberry Pi 4, it’s working fine playing local media files.
Now I am wondering if it can play BBC Radio stream. I have a playlist of BBC Radio streams
from https://garfnet.org.uk/download/radio/20231029-bbc-radio-with-rewind.m3u and I have copied it to /var/lib/mopidy/m3u. The list of radio stations appears as a playlist in mopidy clients but I don’t seem to be able to actually play the streams.
I have also tried putting a single item from the playlist into /var/lib/mopidy/http, the line is:-
‘’’
http://as-hls-ww-live.akamaized.net/pool_904/live/ww/bbc_radio_fourfm/bbc_radio_fourfm.isml/bbc_radio_fourfm-audio%3D96000.norewind.m3u8
‘’’
This doesn’t work either.
Do these streams (HLS I think) not work in Mopidy or do I need some more configuration?
Is the extension Mopidy-Stream enabled?
Why are you doing that? Did you tried to play the stream using your Mopidy client? What happened? Did you look at the logs?
It depends of what GStreamer plugins are installed, not of Mopidy.
Matthias_Meulien [1]Matthias_Meulien
August 29
Is the extension Mopidy-Stream enabled?
Yes (extract from ‘mopidyctl config’) :-
[stream]
enabled = true
protocols =
http
https
mms
rtmp
rtmps
rtsp
metadata_blacklist =
timeout = 5000
chrisisbd:
I have also tried putting a single item from the playlist into
/var/lib/mopidy/http
Why are you doing that? Did you tried to play the stream using your
Mopidy client? What happened? Did you look at the logs?
Well, I actually want to play the single stream most of the time
(Radio 4), rather than having to select it from the play list.
Basically nothing happens at all when I try to play the stream with my
client but I find most multimedia programs so counter-intuitive that
I’m not convinced I’m actually asking it to do the right thing.
Which logs should I be looking at? There’s no errors from Mopidy that
I can see in syslog.
chrisisbd:
Do these streams (HLS I think) not work in Mopidy or do I need some
more configuration?
It depends of what GStreamer plugins are installed, not of Mopidy.
So how can I tell whether the right GStreamer are there? It would
seem as if they’re there :-
root@homepi:/var/log# gst-inspect-1.0 | grep -i HLS
adaptivedemux2: hlsdemux2: HLS Demuxer
typefindfunctions: application/x-hls: m3u8
I’m sorry to report that HLS streams in Mopidy are broken. They’ve been that way for a long time as a consequence of how we handle playlists. It’s been great if someone could fix it.
1 Like
Ah, thank you, at least that means I don’t need to waste any more
time trying to fix my installation.
Well, I picked a random URL (http://as-hls-ww-live.akamaized.net/pool_904/live/ww/bbc_radio_three/bbc_radio_three.isml/bbc_radio_three-audio=320000.m3u8 precisely) in the .m3u URL you sent and I’ve added the random URL to my Mopidy client (Argos, using “add stream to tracklist…” in main menu) and… it works.
Done the same with many other URL from the .m3u file; Some play a standard message saying that the program is not available right now, others just play music, programs, etc. ffprobe reports that all those streams are HLS streams.
So, it’s not clear to me what is not working… Remote playlists? HLS streams are working on my side.
matthias@argos:~ $ gst-inspect-1.0 | grep hls
adaptivedemux2: hlsdemux2: HLS Demuxer
hls: hlsdemux: HLS Demuxer
hls: hlssink: HTTP Live Streaming sink
hls: hlssink2: HTTP Live Streaming sink
libav: avmux_hls: libav Apple HTTP Live Streaming muxer
typefindfunctions: application/x-hls: m3u8
matthias@argos:~ $ sudo mopidyctl deps
Running "/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps" as user mopidy
Executable: /usr/bin/mopidy
Platform: Linux-6.6.31+rpt-rpi-v7-armv7l-with-glibc2.36
Python: CPython 3.11.2 from /usr/lib/python3.11
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
requests: 2.31.0 from /usr/local/lib/python3.11/dist-packages
charset-normalizer: 3.3.2 from /usr/local/lib/python3.11/dist-packages
idna: 3.7 from /usr/local/lib/python3.11/dist-packages
urllib3: 2.2.1 from /usr/local/lib/python3.11/dist-packages
certifi: 2024.2.2 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
tornado: 6.4 from /usr/local/lib/python3.11/dist-packages
Mopidy-InternetArchive: 3.0.1 from /usr/local/lib/python3.11/dist-packages
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
cachetools: 5.2.0 from /usr/lib/python3/dist-packages
requests: 2.31.0 from /usr/local/lib/python3.11/dist-packages
charset-normalizer: 3.3.2 from /usr/local/lib/python3.11/dist-packages
idna: 3.7 from /usr/local/lib/python3.11/dist-packages
urllib3: 2.2.1 from /usr/local/lib/python3.11/dist-packages
certifi: 2024.2.2 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
uritools: 4.0.0 from /usr/lib/python3/dist-packages
Mopidy-Podcast: 3.0.1 from /usr/lib/python3/dist-packages
Mopidy-Local: 3.2.1 from /usr/lib/python3/dist-packages
Mopidy-Iris: 3.69.3 from /usr/local/lib/python3.11/dist-packages
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
Mopidy-SomaFM: 2.0.2 from /usr/local/lib/python3.11/dist-packages
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
requests: 2.31.0 from /usr/local/lib/python3.11/dist-packages
charset-normalizer: 3.3.2 from /usr/local/lib/python3.11/dist-packages
idna: 3.7 from /usr/local/lib/python3.11/dist-packages
urllib3: 2.2.1 from /usr/local/lib/python3.11/dist-packages
certifi: 2024.2.2 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
Mopidy-Bandcamp: 1.1.5 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
Mopidy-Listenbrainz: 0.2.1 from /usr/local/lib/python3.11/dist-packages
Mopidy: 3.4.2 from /usr/local/lib/python3.11/dist-packages
Pykka: 4.0.2 from /usr/local/lib/python3.11/dist-packages
setuptools: 69.5.1 from /usr/local/lib/python3.11/dist-packages
GStreamer: 1.22.0.0 from /usr/lib/python3/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.42.2
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
mad
How long did it work for?
How long did it work for?
I’d say it stopped after >30 minutes; But it didn’t crash (not sure if it’s what you have in mind), I stopped manually.
HLS streams are split into chunks (segments), each lasting just a few seconds. The URIs for the chunks are provided in an m3u8 playlist file which is updated as new chunks are produced and old ones removed as they become obsolete. The main m3u8 playlist for the stream contains a segment list for different quality streams.
So you can load the initial playlist, take the first item in that list, get that segment list and start playing the first segment and then the next and so on, until you get to the end and we’ll stop. That’s what our normal playlist handling code does. But our code won’t re-load the segment playlist when it updates with new chunks, so we’ll stop prematurely. We need something to realise these HLS streams should be handled differently.