[Icecast] Streaming OGG/Vorbis files dies on track change
jordan at coolmic.net
Tue Jul 6 18:35:23 UTC 2021
My guess is that it's 1 of 2 things:
1) Your Ogg/Vorbis files are not encoded uniformly (i.e. differing
smaplerates/quality/num. of channels/etc.)
2) Your files need a trim :) Try this bash script on a sample of problem
files and see if it helps:
# Fixes end-of-stream bug with ogg vorbis files so they don't
# cause some players to crash when moving to a new song in the
for FILE in $(find /path/to/oggfiles -name '*.ogg'); do
cat /dev/null | vorbiscomment -a $FILE;
On 7/5/21 10:22 PM, kit wrote:
> Hi Philipp,
> I was concerned about the mountpoint name as well afterwards so now in
> my tests I used stream8001.ogg. But this did not change anything in the
> behaviour as I still had the same issues.
> Testing was re-done in a virtual machine and examined the access.log as
> suggested. I can confirm that there is only 1 SOURCE entry for the
> source client at runtime.
> EZSTREAM with ogg metadata sent
> 1/220.127.116.11 - - [06/Jul/2021:12:05:41 +0800] "SOURCE /stream8001.ogg
> HTTP/1.0" 401 331 "-" "libshout/2.4.5" 0//
> //10.1.1.20 - - [06/Jul/2021:12:12:34 +0800] "GET /stream8001.ogg
> HTTP/1.1" 200 5648489 "-" "Clementine 1.3.1" 405 <--------Clementine
> dies about 3 minutes after track change. My associate reports that his
> Windows Media Player dies too.//
> //10.1.1.20 - - [06/Jul/2021:12:16:36 +0800] "GET /stream8001.ogg
> HTTP/1.1" 200 9865567 "-" "Mozilla/5.0" 623 <----- keeps playing but
> reports the following discontinuity during a track change .../
> chris at asus-roc:~> mpv http://10.1.1.41:8001/stream8001.ogg
> (+) Audio --aid=1 'All Directions Are Up' (vorbis 2ch 44100Hz)
> File tags:
> Artist: Cyber Zen Sound Engine
> Album: Moonscapes: How Stones Become Enlightened
> Album_Artist: Cyber Zen Sound Engine
> Genre: Electronica
> Title: All Directions Are Up
> Track: 1
> AO: [jack] 44100Hz stereo 2ch floatp
> A: 00:03:34 / 00:03:39 (98%) Cache: 4.6s/165KB
> /*[lavf] Linearizing discontinuity: 0.000000 -> 246.296599*//*
> *//*[lavf] Linearizing discontinuity: 246.293696 -> 246.296599*/
> A: 00:03:39 / 00:03:44 (98%) Cache: 5.0s/157KB
> File tags:
> Artist: Fanger & Schönwälder
> Album: Analog Overdose (Featuring Lutz Ulbrich)
> Album_Artist: Fanger & Schönwälder
> Genre: Disco
> Title: Analog Moods
> A: 00:10:21 / 00:10:26 (99%) Cache: 4.6s/266KB
> I next used Mixxx to stream Ogg files without metadata - all listening
> clients performed ok during track changes. Naturally those clients could
> not report any track titles/artists.
> /127.0.0.1 - - [06/Jul/2021:12:51:26 +0800] "SOURCE /stream8001.ogg
> HTTP/1.0" 401 331 "-" "libshout/2.4.1" 0/
> Next Mixxx with ogg metadata was streamed - same problems as the
> EZSTREAM results above.
> The Mixxx manual has this nice little mention -
> /*Dynamically update Ogg Vorbis metadata*//: Due to flaws in some
> streaming clients, updating Ogg Vorbis metadata dynamically can cause
> listener glitches and disconnections. Check this box to update the
> metadata anyway. Some players that listeners can use have bugs that can
> cause audio glitches or disconnections when the Ogg Vorbis metadata is
> updated dynamically. If this is not a problem, you can enable this
> Since EZSTREAM or Ices can not stream MP3 or OGG (without it's metadata)
> I am ditching them both. MPD+ncmpcpp work nicely last night on a test
> rig streaming MP3 so I am rebuilding my server with those.
> But I would still be curious about this issue as to what happened.
> On 5/7/21 8:04 pm, Philipp Schafft wrote:
>> Good afternoon,
>> On Sun, 2021-07-04 at 10:24 +0800, kit wrote:
>>> I'm having issues with streaming OGG/Vorbis files to Icecast. I am
>>> using Ezsteam to stream a playlist of Ogg files from the command
>>> line, but when there is a track change the stream stops in clients
>>> like Clementine and Windows Media Player. MPV client reports a
>>> discontinuity but carries on playing.
>>> I have also test using Mixxx to stream as Ogg to the same icecast
>>> server but it has the same issue. Only B.U.T.T. seems to handle track
>>> changes well.
>>> This is my mount details from the icecast XML file.
>>> <mount type="normal">
>> That is a strange name for a mount.
>> Please also keep in mind that some broken players expect Ogg/Vorbis
>> streams to have an URI ending with ".ogg". This is NOT a problem of
>> Icecast, but of some players. So consider to change this.
>>> There are no issues with streaming MP3 at all as far as I can see.
>>> But since I need to use EZstream OGG format is my only option.
>>> I'm looking at MPD+ncmpcpp as an alternative (more reading) but I
>>> would like to stick with Ezstream at this point since I have it
>>> This track change issue with ogg files seems to be a known issue.
>>> But reading the docs a bit more I wonder if the use of a fallback-
>>> mount setting using an ogg file of 5 secs of silence would fix
>> It depends on what the actual problem is. But I suspect it is not that
>> the source client drops the connection. A fallback would only help in
>> that case.
>> You can check this by having a look at your access.log. If it lists one
>> SOURCE, or PUT request per track, than this is the problem (and the
>> source client is having some issue). If you see only one SOURCE, or PUT
>> request for each runtime of the source client, then it does at least
>> this correctly.
>> Is there a public URI to your stream so we can have a look?
>> With best regards,
>> Icecast mailing list
>> Icecast at xiph.org
> Icecast mailing list
> Icecast at xiph.org
Cool Mic Project Manager
More information about the Icecast