MPD
MPD copied to clipboard
MusicPlayerDaemon
MPD streams played on browsers stop after some song changes
Bug report
Describe the bug
Using latest Firefox (~v67+) the stream (either through
Expected Behavior
The stream shouldn't stop.
Actual Behavior
Music stops by itself; Stream keeps being downloaded on Firefox, stops download on Chrome.
Version
root@localhost:~# mpd --version Music Player Daemon 0.22~git (v0.21.10-381-ga17f420d6) Copyright 2003-2007 Warren Dukes [email protected] Copyright 2008-2018 Max Kellermann [email protected] This is free software; see the source for copying conditions. There is NO warranty; not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Database plugins: simple proxy upnp
Storage plugins: local smbclient udisks nfs curl
Neighbor plugins: smbclient upnp udisks
Decoders plugins: [mad] mp3 mp2 [mpg123] mp3 [vorbis] ogg oga [oggflac] ogg oga [flac] flac [opus] opus ogg oga [sndfile] wav aiff aif au snd paf iff svx sf voc w64 pvf xi htk caf sd2 [audiofile] wav au aiff aif [dsdiff] dff [dsf] dsf [hybrid_dsd] m4a [faad] aac [mpcdec] mpc [wavpack] wv [modplug] 669 amf ams dbm dfm dsm far it med mdl mod mtm mt2 okt s3m stm ult umx xm [mikmod] amf dsm far gdm imf it med mod mtm s3m stm stx ult uni xm [sidplay] sid mus str prg P00 [wildmidi] mid [fluidsynth] mid [adplug] amd d00 hsc laa rad raw sa2 [ffmpeg] 16sv 3g2 3gp 4xm 8svx aa3 aac ac3 adx afc aif aifc aiff al alaw amr anim apc ape asf atrac au aud avi avm2 avs bap bfi c93 cak cin cmv cpk daud dct divx dts dv dvd dxa eac3 film flac flc fli fll flx flv g726 gsm gxf iss m1v m2v m2t m2ts m4a m4b m4v mad mj2 mjpeg mjpg mka mkv mlp mm mmf mov mp+ mp1 mp2 mp3 mp4 mpc mpeg mpg mpga mpp mpu mve mvi mxf nc nsv nut nuv oga ogm ogv ogx oma ogg omg opus psp pva qcp qt r3d ra ram rl2 rm rmvb roq rpl rvc shn smk snd sol son spx str swf tak tgi tgq tgv thp ts tsp tta xa xvid uv uv2 vb vid vob voc vp6 vmd wav webm wma wmv wsaud wsvga wv wve [gme] ay gbs gym hes kss nsf nsfe sap spc vgm vgz [pcm]
Filters: libsamplerate soxr
Tag plugins: id3tag
Output plugins: shout null fifo sndio pipe alsa ao openal pulse jack httpd recorder
Encoder plugins: null vorbis opus lame twolame wave flac shine
Archive plugins: [bz2] bz2 [zzip] zip [iso] iso
Input plugins: file archive alsa tidal curl ffmpeg smbclient nfs mms cdio_paranoia
Playlist plugins: extm3u m3u pls xspf asx rss soundcloud flac cue embcue
Protocols: file:// alsa:// tidal:// http:// https:// gopher:// rtp:// rtsp:// rtmp:// rtmpt:// rtmps:// smb:// nfs:// mms:// mmsh:// mmst:// mmsu:// cdda://
Other features: avahi dbus udisks epoll icu inotify ipv6 systemd tcp un
Here's mpd config, with comments removed (/usr/local/etc/mpd.conf):
audio_output {
type "httpd"
port "8123"
encoding "ogg" # optional
encoder "opus"
opustags "yes"
name "My Shout Stream"
host "localhost"
# port "8764"
mount "/mymountpoint"
password "mypassword"
# quality "5.0"
bitrate "192000"
format "44100:16:2"
protocol "icecast2" # optional
user "source" # optional
description "My Stream Description" # optional
url "http://example.com" # optional
# genre "jazz" # optional
public "no" # optional
# timeout "2" # optional
mixer_type "software" # optional
}
Why do you believe this is a MPD problem?
With opustags yes, MPD needs to start a new Ogg stream after each song change, because only a new stream is allowed to send tags; and some clients may stop playing when the first Ogg stream ends. This may rather be a client problem.
Tried running a Firefox and Clementine stream at the same time. Clementine seems to have failed at the first song change, while Firefox kept going.
Probably unrelated but... Changed it to vorbis. Clementine shows this on song change:
Decided to try liquidsoap. Vorbis setting (I had the same problem with vorbis or opus in mpd) Being streaming for like 1.5 hours, with metadata, and no problems so far. So this might be something mpd can fix? Overall the mpd+mpc experience is better for Icecast streaming, so I'd prefer mpd. But if stream keeps working with liquidsoap I'll just use that for now. Might try with opus next and report back.
Btw I just noticed opus uses a different sample rate: "Must be one of: 8000, 12000, 16000, 24000 or 48000" (that's from liquidsoap documentation). Maybe my set sample rate is messing things up.
I don't have liquidsoap. Maybe they're using a trick I don't know. Can you capture liquidsoap's stream data during a song change and upload it for me?
Not sure if this is useful but here's a tshark capture of localhost tcp on the port used to connect liquidsoap and icecast. It starts around a minute before a song changes and ends some seconds after the next song starts. If you have a better idea on how to capture the data I can try. https://termbin.com/mmmu
That's not a tshark capture. That's the text output of tshark which contains only some useless metadata.
Somehow I was actually able to replicate issue. I had to leave it running for quite a while, though. Packets still flowing (containing audio data), and firefox still has play icon on tab, it's not paused, but it's not playing, and time of audio element isn't advancing, neither in playtime, nor in overall stream capacity. I wasn't exactly there when the stream stopped playing, though, so I can't really tell what was happening in wireshark session back when it stopped. Clicking pause/unpause doesn't do anything, stream is just stuck at this point. In irc, madprops mentioned that it happens for both vorbis and opus (with opustags yes). I suspect there could be issue with firefox handling of chained streams (because iirc normal vorbis output is chained by default). I can't reject possibility that we're doing something wrong in both vorbis and opus encoders, also. Maybe it didn't like some of chaining values which happen rarely? I guess we can't know yet, this needs more debugging, which is annoying as likehood of this happening isn't high enough to be easily testable.
I've actually just got curl -s streamurl | opusdec --force-wav --float - - | aplay -t wav - 2>/dev/null to hang up.
It seems likelihood increases when stream is laggy during track change, and can be replicated pretty quickly in bad network conditions.
Restarting stream makes it work again.
Could it actually be dropping some of packets if clients can't keep up, and then when stream gets chained, it changes stream identifier, but laggy clients won't get chaining packets and thus can't recognise continued stream?
I don't know if my current observations are relevant though.
Yeah I just had some bad network problems, and liquidsoap just failed right after the end of current song. Probably not an mpd thing.
Not sure if it was actual network problems or the song just got choppy for some reason. (My network bandwidth indicator was showing normal download speeds).
This was an exceptionally laggy case though, when I tried it with mpd the stream would go as normal before dying. So maybe it's a normal case of icecast killing the stream on a timeout due to actual bad network.
It wouldn't surprise me if it was common issue across mpd and icecast, as doing it the right way would be quite a bit more complicated, and resetting connection wouldn't be much better as it works out just fine if dropped packets aren't stream chaining ones. Song being choppy is also indication of that, because when it starts dropping packets, they get cut and it doesn't sound good. Glad we got it figured out, but I don't think solution in mpd's httpd is going to look pretty, and then we also have the same problem with icecast. I still think it should be fixed, though, as it's annoying as hell when that happens.
With several streaming clients (VLC, MALP, Firefox), I found the stream would terminate on client at the end of each song. For me, I had the lame encoder being used and simply switching to vorbis has resolved the problem for me. v0.23.12 built from source, full output config below:
audio_output {
type "httpd"
name "MPD HTTP Audio Stream"
encoder "lame" # change to vorbis for seamless stream playback
port "8000"
bind_to_address "0.0.0.0"
bitrate "320"
max_clients "0"
always_on "yes"
}
Seems vorbis works for some and lame works for others? This is part of the conf I have:
audio_output {
type "shout"
# port "8123"
encoding "ogg" # optional
encoder "vorbis"
# opustags "yes"
name "redacted"
host "localhost"
port "redacted"
mount "/redacted.ogg"
password "redacted"
# quality "5.0"
bitrate "192"
format "44100:16:2"
protocol "icecast2" # optional
user "source" # optional
description "redacted" # optional
url "http://example.com" # optional
# genre "jazz" # optional
public "no" # optional
# timeout "2" # optional
mixer_type "software" # optional
}
It stills pauses for me after certain songs. It can play 5 songs correctly in Firefox and then fail to play the next one and stop transmitting, even though Firefox still treats the tab as playing, it keeps showing the playing/audio icon. I'm not sure what the pattern is. But I guess mp3 <--> ogg change problems.
But my case is probably a niche thing. Especially since Icecast is also in the mix. So feel free to close this.