Hi, thanks in advance for any help that can be provided for this
head-scratcher.
I'm configuring a new server and can't get it to move listen clients to
the fallback file when the source client disconnects. I probably have a
misconfiguration in icecast.xml.
Here is the <mount> section:
<mount type="normal">
<mount-name>/stream.mp3</mount-name>
<burst-size>65536</burst-size>
<fallback-mount>/fallbacks/Generic_Festival_fallback_192kHz.mp3</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
<no-yp>1</no-yp>
</mount>
Seems okay. Here is the <paths> section:
<paths>
<!-- basedir is only used if chroot is enabled -->
<basedir>/usr/share/icecast2</basedir>
<!-- Note that if <chroot> is turned on below, these paths
must both
be relative to the new root, not the original root -->
<logdir>/var/log/icecast2</logdir>
<webroot>/usr/share/icecast2/web</webroot>
<adminroot>/usr/share/icecast2/admin</adminroot>
<alias source="/" destination="/status.xsl"/>
</paths>
and
<chroot>1</chroot>
<webroot> is /usr/share/icecast2/web and the fallback file is in
"fallbacks" under it:
pi at Pi:/usr/share/icecast2/web/fallbacks $ ls
400Hz_0dBFS_sine_15m.mp3 Generic_Festival_fallback_128kHz.mp3
fallback_400hz_minus_20dB.mp3 Generic_Festival_fallback_192kHz.mp3
Here is icecast's error.log when it starts up:
[2017-04-28 21:34:07] INFO main/main Icecast 2.4.0 server started
[2017-04-28 21:34:07] INFO connection/get_ssl_certificate No SSL capability
[2017-04-28 21:34:07] INFO yp/yp_update_thread YP update thread started
[2017-04-28 21:34:07] INFO source/source_fallback_file mountpoint
/fallbacks/Generic_Festival_fallback_192kHz.mp3 is reserved
[2017-04-28 21:34:07] WARN format/format_get_type Unsupported or legacy stream
type: "audio/mpeg". Falling back to generic minimal handler for best
effort.
[2017-04-28 21:34:07] INFO source/source_main listener count on
/fallbacks/Generic_Festival_fallback_192kHz.mp3 now 0
So server has found the fallback. No clients connected.
Okay, start a stream pointed to /stream and the log adds:
[2017-04-28 21:40:36] INFO connection/_handle_source_request Source logging in
at mountpoint "/stream"
[2017-04-28 21:40:36] WARN format/format_get_type Unsupported or legacy stream
type: "audio/mpeg". Falling back to generic minimal handler for best
effort.
[2017-04-28 21:40:36] INFO admin/admin_handle_request Received admin command
metadata on mount "/stream"
[2017-04-28 21:40:36] INFO admin/command_metadata Metadata on mountpoint
/stream changed to "asdfsdf"
[2017-04-28 21:40:36] INFO source/source_main listener count on /stream now 0
Connect a listen client:
[2017-04-28 21:41:40] INFO source/source_main listener count on /stream now 1
The listen-client is receiving the stream.
Now, if I kill the source mount client:
[2017-04-28 21:42:48] INFO source/get_next_buffer End of Stream /stream
[2017-04-28 21:42:48] INFO source/source_shutdown Source "/stream"
exiting
[2017-04-28 21:42:48] INFO source/source_clear_source 1 active listeners on
/stream released
and the listen-client exits. There seems to be no attempt here to move
the listen-client to the fallback mount
("/fallbacks/Generic_Festival_fallback_192kHz.mp3").
If I try to connect a listen-client when the /source client is not
running, it doesn't find a mountpoint, server is not connecting it up.
I get the same behavior with two different types of listen-clients, so I
reckon I've got something not quite right in the config file, but
error.log isn't revealing it to me.
It baffles science.
--
That Jack Elliott
(541) 848 7021
KPOV 88.9 FM High Desert Community radio
Producer, The Wednesday Point
Host, The Sunday Classics
Jack Elliott
2017-May-02 01:37 UTC
[Icecast] Server not moving clients to fallback (solved)
Solved. Changing "<mount-name>/stream.mp3</mount-name>" to "<mount-name>/stream</mount-name>" fixed it. The supplied default icecast.xml has "example.ogg" for the mount-name, suggesting that one needs an extension. Icecast will cheerfully stream the mount whether it is called "stream" or "stream.mp3" (my source is mp3 format) but doesn't like to switch to the fallback-mount. I reckon that the supplied config file has "example.ogg" as the mount and "example2.ogg" as the fallback-mount is because, as the documentation states, the mount and the fallback both need to be the same type else players might get confused. I have also found that in the case of mp3, they also need to be the same bitrate for the same reason. -- That Jack Elliott (541) 848 7021 KPOV 88.9 FM High Desert Community radio Producer, The Wednesday Point Host, The Sunday Classics On 04/28/2017 09:53 PM, Jack Elliott wrote:> Hi, thanks in advance for any help that can be provided for this > head-scratcher. > > I'm configuring a new server and can't get it to move listen clients > to the fallback file when the source client disconnects. I probably > have a misconfiguration in icecast.xml. > > Here is the <mount> section: > > <mount type="normal"> > <mount-name>/stream.mp3</mount-name> > <burst-size>65536</burst-size> > <fallback-mount>/fallbacks/Generic_Festival_fallback_192kHz.mp3</fallback-mount> > <fallback-override>1</fallback-override> > <fallback-when-full>1</fallback-when-full> > <no-yp>1</no-yp> > </mount> > > Seems okay. Here is the <paths> section: > > <paths> > <!-- basedir is only used if chroot is enabled --> > <basedir>/usr/share/icecast2</basedir> > > <!-- Note that if <chroot> is turned on below, these paths > must both > be relative to the new root, not the original root --> > <logdir>/var/log/icecast2</logdir> > <webroot>/usr/share/icecast2/web</webroot> > <adminroot>/usr/share/icecast2/admin</adminroot> > <alias source="/" destination="/status.xsl"/> > </paths> > > and > > <chroot>1</chroot> > > <webroot> is /usr/share/icecast2/web and the fallback file is in > "fallbacks" under it: > > pi at Pi:/usr/share/icecast2/web/fallbacks $ ls > 400Hz_0dBFS_sine_15m.mp3 Generic_Festival_fallback_128kHz.mp3 > fallback_400hz_minus_20dB.mp3 Generic_Festival_fallback_192kHz.mp3 > > Here is icecast's error.log when it starts up: > > [2017-04-28 21:34:07] INFO main/main Icecast 2.4.0 server started > [2017-04-28 21:34:07] INFO connection/get_ssl_certificate No SSL > capability > [2017-04-28 21:34:07] INFO yp/yp_update_thread YP update thread started > [2017-04-28 21:34:07] INFO source/source_fallback_file mountpoint > /fallbacks/Generic_Festival_fallback_192kHz.mp3 is reserved > [2017-04-28 21:34:07] WARN format/format_get_type Unsupported or > legacy stream type: "audio/mpeg". Falling back to generic minimal > handler for best effort. > [2017-04-28 21:34:07] INFO source/source_main listener count on > /fallbacks/Generic_Festival_fallback_192kHz.mp3 now 0 > > So server has found the fallback. No clients connected. > > Okay, start a stream pointed to /stream and the log adds: > > [2017-04-28 21:40:36] INFO connection/_handle_source_request Source > logging in at mountpoint "/stream" > [2017-04-28 21:40:36] WARN format/format_get_type Unsupported or > legacy stream type: "audio/mpeg". Falling back to generic minimal > handler for best effort. > [2017-04-28 21:40:36] INFO admin/admin_handle_request Received admin > command metadata on mount "/stream" > [2017-04-28 21:40:36] INFO admin/command_metadata Metadata on > mountpoint /stream changed to "asdfsdf" > [2017-04-28 21:40:36] INFO source/source_main listener count on > /stream now 0 > > Connect a listen client: > > [2017-04-28 21:41:40] INFO source/source_main listener count on > /stream now 1 > > The listen-client is receiving the stream. > > Now, if I kill the source mount client: > > [2017-04-28 21:42:48] INFO source/get_next_buffer End of Stream /stream > [2017-04-28 21:42:48] INFO source/source_shutdown Source "/stream" > exiting > [2017-04-28 21:42:48] INFO source/source_clear_source 1 active > listeners on /stream released > > and the listen-client exits. There seems to be no attempt here to > move the listen-client to the fallback mount > ("/fallbacks/Generic_Festival_fallback_192kHz.mp3"). > > If I try to connect a listen-client when the /source client is not > running, it doesn't find a mountpoint, server is not connecting it up. > > I get the same behavior with two different types of listen-clients, so > I reckon I've got something not quite right in the config file, but > error.log isn't revealing it to me. > > It baffles science. >