[Icecast] <fallback-override>

[Thomas B. Rücker]

Hi,

On 3/17/19 12:00 AM, Per Gunnarsson wrote:
> I have a fallback mount point with <fallback-override>.


I'm going to guess you mean this section:

<mount type="normal">
    <mount-name>/stream.opus</mount-name>
    <fallback-mount>/pausmusik.opus</fallback-mount>
    <fallback-override>1</fallback-override>
    <fallback-when-full>1</fallback-when-full>
    <public>1</public>
    <stream-name>mustafejen opus</stream-name>
    <stream-description>Stream from Ersboda</stream-description>
    <stream-url>https://mustafejen.se/~per</stream-url>
    <genre>Alternative, eclectic</genre>
    <bitrate>32</bitrate>
    <type>audio/ogg</type>
    <subtype>opus</subtype>
    <hidden>0</hidden>
    <burst-size>65536</burst-size>
    <mp3-metadata-interval>4096</mp3-metadata-interval>  
</mount>


Note: (mp3-)metadata-interval does not make sense in the context of an Ogg encapsulated stream. Ogg supports proper metadata and doesn't rely on blunt injection into the bit-stream. This doesn't change behavior, it's just ignored.



> When my source client reconnects, the media player is moved mack to the
> right mount point but the media players I have tried (mplayer and VLC)
> keep playing the fallback.


I took a look at your actual stream content. The fallback looks like it is coming from a static file containing one Ogg stream. At least that's my guess why the fallback is coming in at 20x the bandwidth of the mount, while both seem to be averaging 32kbit codec bitrate.

This poses several potential problems out of which you are experiencing at least one:

* Fallback to file should be considered last resort and only used for minimal amounts of time. Seconds at most. Icecast does not do any special bandwidth limiting while serving out files, that means that in the 'worst case' you might be feeding the client data at 
up to a million times the actual bitrate. This can lead to problems like the client being overwhelmed and dropping (rare/unlikely/broken), the client caching at incoming rate and blowing up in memory, the client filling its cache that's potentially several megabytes in size, etc. The last named case is likely your problem, the player now contains potentially minutes or hours of fallback 'stream' data and will take a *really* long time to reach the data from the actual mount and start playing that back (it's FIFO).

* As a single Ogg 'element' there is ever only one 'serialnumber'. Most players can deal with this, but some will throw errors or stop playback. opusdec for example says: `Error: Apparent chaining without changing serial number (1603481952==1603481952).`
I'd suggest to have a file that contains *two* chain elements with different serial numbers. This way they will alternate and thus sidestep the problem.

In general we highly recommend to use *actual* streams as fallback. It can be something really simple that is just sending out pre-encoded concatenated data at codec bitrate (think IceS2 in case of Vorbis). Again ideally at least two serial numbers should occur to avoid client problems (e.g. two *different* files, *not* copies of the same file!)


> Is this because of my source client (liquidsoap), icecast or the media
> players?
> I think I noticed some message in mplayer about mime type or something.


As outlined above it's a bit of a compound problem, but it can be
addressed completely on the server/source side.


HTH, cheers,


Thomas