<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 5/29/2020 4:40 AM, Philipp Schafft
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1590752420.2378.68.camel@de.loewenfelsen.net">
<pre class="moz-quote-pre" wrap="">Good afternoon,
On Fri, 2020-05-22 at 05:52 -0700, Jack Elliott wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 5/21/2020 1:10 AM, Philipp Schafft wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi, I'm pretty sure this isn't going to be possible, but I'll ask. I'd
like to add a <stream-title> to my fallback mount so when the main
stream mount drops and the fallback kicks in, that the connected player
shows a different title.
Then back again, of course.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The metadata data is in the responsibility of the source client. Icecast
just relays that information. As soon as the client hits the fallback
stream the metadata of the fallback stream is sent to the client.
So, best advice would be to check the configuration of the fallback's
source client.
With best regards,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Thank you.
In our case, the fallback is an mp3 file. Is there a specific metadata
"tag" I should use for the identifying string?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I think there is some misunderstanding here:
When you set a file as fallback Icecast will just send that file as if
serving it by a direct request. This comes with two effects:
* Icecast will send it as fast as it can. Sending at "the correct
speed" is not something Icecast manages. It always forwards data
as fast as it can. Sending at a real time speed is part of the
source client's work. And as your disk is normally much faster
than your network connection Icecast will send it with full
speed.
* For legacy codecs only: Legacy codecs (that is MP3 and AAC) do
not implement metadata at all. If stored in a file it ID3 is
used. ID3 however is a container that contains the actual file.
Exactly like a Zip file contains other files. However ID3 can
not be streamed. Trying to do so may or may not break listener
clients. For streaming Nullsoft invented a, also legacy protocol
called ICY. Icecast uses this for MP3 and AAC if requested by
the client. This protocol contains (crippled) metadata. However
as it is a network protocol it can not be used for storage.
Long story short: It is generally recommended to have a local source
client that serves the fallback. Otherwise timing will break.
For legacy codecs it is also important as there can not be metadata
without a proper source client.
I hope that helps. :)
With best regards,
</pre>
</blockquote>
<p>Thank you.</p>
<p>Perhaps it would be better for me to explain my goal. <br>
</p>
<p>Our Icecast server is used by our radio station hosts to send
live shows from their home studios. Normally they would do their
shows from within the radio station, but with COVID-19 they are
urged to stay home and connect to the Icecast server using their
personal mixers, encoders, etc. <br>
</p>
<p>When a host connects as a source-mount the Icecast server makes
their stream available on the station's LAN. In the broadcast
studio, when it is time to broadcast the show, our radio
automation software (in our case, Rogue Amoeba's "MegaSeg" playout
software), connects as a listen-client and thereby sends the
remote stream to the FM transmitter and to our listening audience.
<br>
</p>
<p>If the source-client is not yet connected (maybe she is late with
her show), the listen-client still must be able to connect even if
there is no audio. Else if she comes in a bit later, the
listen-client may have disconnected. <br>
</p>
<p><u>So my first question</u> is what happens when the
listen-client connects to the mountpoint when there is no
source-client connected. Is there a "silent stream", or is there
nothing?<br>
</p>
<p>We need the stream to be always available for the listen-client
to connect to, even if there is no source-client mounted, or if
the source-client disconnects early, possible due to internet
congestion. <br>
</p>
<p>To assure that there is a stream to connect to I have a silent
mp3 as a fallback, so even if the source-client is not connected,
the listen-client still has a stream to connect to. <br>
</p>
<p>Is this necessary? <br>
</p>
<pre class="moz-signature" cols="72">--
That Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM High Desert Community radio
(541) 848 7021
</pre>
<blockquote type="cite"
cite="mid:1590752420.2378.68.camel@de.loewenfelsen.net">
</blockquote>
</body>
</html>