Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPD streams played on browsers stop after some song changes #592

Open
madprops opened this issue Jun 26, 2019 · 13 comments

Comments

Projects
None yet
3 participants
@madprops
Copy link

commented Jun 26, 2019

Bug report

Describe the bug

Using latest Firefox (~v67+) the stream (either through or tags) stops playing on some song changes, the frequency seems to be variable but it can happen in a couple of minutes.
This is using opus encoding and opustags "yes" (but I think it also happens with vorbis).
This happens through Icecast but also on mpd's httpd server.
As a test I've been running opus with opustags "no" for almost 2 hours (on the httpd server) and it hasn't failed.
When this happens, the music just stops playing, but by looking at the bandwidth usage I can see the stream is still being downloaded. For instance if I set the bitrate at 192kbps, my bandwidth shows it's downloading roughly that, or that exactly.
I tested running a stream on Firefox and Chrome (opus, opustags "yes") at the same time. Chrome failed quickly, but at least it stopped the stream download.

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 warren.dukes@gmail.com
Copyright 2008-2018 Max Kellermann max.kellermann@gmail.com
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

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 26, 2019

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
}
@MaxKellermann

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

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.

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

I wasn't sure. I also made a bug report in Firefox.

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

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.

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

Probably unrelated but...
Changed it to vorbis.
Clementine shows this on song change:

screenshot_9

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

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.

@MaxKellermann

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

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?

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

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

@MaxKellermann

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

That's not a tshark capture. That's the text output of tshark which contains only some useless metadata.

@akklesed

This comment has been minimized.

Copy link

commented Jun 27, 2019

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.

@akklesed

This comment has been minimized.

Copy link

commented Jun 27, 2019

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.

@madprops

This comment has been minimized.

Copy link
Author

commented Jun 28, 2019

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.

@akklesed

This comment has been minimized.

Copy link

commented Jun 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.