[Icecast] Streaming OGG/Vorbis files dies on track change
therealkitman at iinet.net.au
Wed Jul 7 00:09:26 UTC 2021
The oggs vary from 100 to 130 kbps but when sent via Mixxx they are all
encoded as 128kbps. And trimming the comments made no difference.
On 7/7/21 2:35 am, Jordan Erickson wrote:
> Hi Kit,
> 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
> # stream.
> for FILE in $(find /path/to/oggfiles -name '*.ogg'); do
> cat /dev/null | vorbiscomment -a $FILE;
> Jordan Erickson
> 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/184.108.40.206 - - [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 checkbox./
>> 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
More information about the Icecast