Icecast audio stream with ogg/opus stops working
Categories
(Core :: Audio/Video, defect, P3)
Tracking
()
People
(Reporter: manuelchaves, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
I have an <audio> tag that connects to an Icecast radio stream.
Source files are either mp3 or ogg.
The stream is encoded through mpd as ogg opus.
I asked in the icecast irc channel:
"Does the stream look like opus encoded?"
"Yes. And the parameters are the same for each logical bitstream, as you would expect from a transcoding setup. Could maybe be about size of metadata or something like that if it only happens with some song changes."
Actual results:
Audio stops. Usually right after a song ends, but I've noticed it happens at the start of some songs.
My network indicator shows that the stream is still being transferred (around 200kbps), but no sound.
Can't see errors in the console or network tabs.
Expected results:
Audio should not stop, and if it does for some reason, the stream should be closed.
|
Reporter | |
Comment 1•5 years ago
|
||
I think it might be related to metadata. Someone in the Icecast channel suggested disabling metadata update from mpd as a workaround to play in browsers. I did that and changed songs a few times, the stream never stopped. The problem is, doing that disables metadata altogether, meaning Icecast can't show artist/title, so I can't use that.
|
|
Reporter | |
Comment 2•5 years ago
|
||
This seems to happen when MPD's opus stream has opustags "yes", and doesn't seem to happen when it has opustags "no".
I opened an issue in the MPD github and got this response:
"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."
|
|
Reporter | |
Comment 3•5 years ago
|
||
I thought that problem didn't happen with liquidsoap as well, but it does. It seems the culprit might be bad connections.
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?
|
|
Reporter | |
Comment 4•5 years ago
|
||
It might have been a case of Icecast closing the connection due to bad network. But still, Firefox should know when a stream has died and close the connection, instead of still downloading the stream. Chrome does this.
|
||
Comment 5•5 years ago
|
||
Hi manuelchaves, there is a test page or a link where I can see if I'm able to reproduce the issue?
Also can you please retest it with the latest Nightly? Here is a link from where you can download the build: https://nightly.mozilla.org/
|
|
Reporter | |
Comment 6•5 years ago
|
||
To make a test page I'd have to make a dedicated mpd stream.
The thing is, the problem doesn't happen with liquidsoap, as in, it doesn't stop, or if it's stops it's very rarely, and probably due to bad network.
The problem about stopping I think relies on mpd, and not firefox.
Although the stream continuing to download data on a stopped stream might still be a problem.
|
||
Comment 7•5 years ago
|
||
(In reply to manuelchaves from comment #6)
To make a test page I'd have to make a dedicated mpd stream.
The thing is, the problem doesn't happen with liquidsoap, as in, it doesn't stop, or if it's stops it's very rarely, and probably due to bad network.
The problem about stopping I think relies on mpd, and not firefox.
Although the stream continuing to download data on a stopped stream might still be a problem.
Does Firefox eventually close the stream or does it continue indefinitely?
It would be great if you can provide instructions or a link describing how you have your mpd stream / icecast setup so we can try to reproduce this locally. Thank you!
|
|
Reporter | |
Comment 8•5 years ago
|
||
You can check the settings I used, in this github issue https://github.com/MusicPlayerDaemon/MPD/issues/592
|
||
Comment 9•5 years ago
|
||
Did this ever work in older versions of Firefox, or was this always a problem with Firefox for you?
|
|
Reporter | |
Comment 10•5 years ago
|
||
Can't specify an exact date, but song stopping on Firefox is an issue reported by others, and experienced by myself, months/years before. While those problems didn't happen in Chrome. I'm not sure if those were the same problems as now since it seems some fixes towards that were made. And it might be better now. If it's too related to mpd or if there's no easy way to debug this, feel free to close the issue.
|
||
Updated•2 years ago
|
|
||
Comment 11•11 months ago
|
||
Ensure that your Icecast server is properly configured to handle OGG/Opus streams. Verify that the appropriate settings for encoding, bitrate, and stream format are properly configured in your Icecast server http://fairfaxautodetailing.com/ configuration file.
|
||
Comment 12•1 month ago
|
||
Hi,
I don't think this is specific to Icecast, and this bug report is basically a revival of https://bugzilla.mozilla.org/show_bug.cgi?id=455165
I'm not sure I ever saw chained ogg work in Firefox, but it's painfully annoying.
I can confirm the bug on Firefox 125.0.2, I sure can try a nightly build…
Description
•