On 5/29/2020 4:40 AM, Philipp Schafft wrote:> Good afternoon,
>
> On Fri, 2020-05-22 at 05:52 -0700, Jack Elliott wrote:
>> On 5/21/2020 1:10 AM, Philipp Schafft wrote:
>>> On Sat, 2020-05-16 at 12:30 -0700, Jack Elliott wrote:
>>>> 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.
>>> 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,
>>>
>> Thank you.
>>
>> In our case, the fallback is an mp3 file. Is there a specific metadata
>> "tag" I should use for the identifying string?
> 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,
Thank you.
Perhaps it would be better for me to explain my goal.
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.
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.
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.
_So my first question_ 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?
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.
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.
Is this necessary?
--
That Jack Elliott
Director of Classical Music Programming
KPOV 88.9 FM High Desert Community radio
(541) 848 7021
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20200529/eb2c5cdf/attachment.html>