Icecast2: Mountpoint buffers at browser playback for a long time - icecast

Question

When I try to play my icecast stream at a browser player or directly by visiting the mountpoint, it lasts up to one to two minutes till I hear any sound. Which setting at icecast does affect such behaviour? My server hardware can´t be the reason. Also the problem affects only the browser - with desktop player there is no buffering time. When I use shoutcast all web player loads just in time.
<icecast>
<location>Earth</location>
<admin>mail#test.test</admin>
<limits>
<clients>200</clients>
<sources>3</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>20</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>60</source-timeout>
<burst-on-connect>0</burst-on-connect>
<burst-size>65535</burst-size>
</limits>
<authentication>
<source-password>hackme</source-password>
<relay-password>hackme</relay-password>
<admin-user>admin</admin-user>
<admin-password>hackme</admin-password>
</authentication>
<!-- {%comment-open-if:icecast.directory.yp-url==""%} -->
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://yp.shoutcast.com</yp-url>
</directory>
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://www.oddsock.org/cgi-bin/yp-cgi</yp-url>
</directory>
<directory>
<yp-url-timeout>15</yp-url-timeout>
<yp-url>http://dir.xiph.org/cgi-bin/yp-cgi</yp-url>
</directory>
<!-- {%comment-close-if:icecast.directory.yp-url==""%} -->
<hostname>test.test</hostname>
<port>8008</port>
<bind-address>1.1.1.1</bind-address>
<!-- Only define a <mount> section if you want to use advanced options,
like alternative usernames or passwords -->
<mount>
<bitrate>128</bitrate>
<mount-name>/mp3</mount-name>
<fallback-override>0</fallback-override>
<fallback-when-full>0</fallback-when-full>
<public>1</public>
<max-listeners>150</max-listeners>
<fallback-mount></fallback-mount>
<genre>alternative</genre>
<type>audio/mpeg</type>
</mount>
<mount>
<bitrate>64</bitrate>
<mount-name>/mobile</mount-name>
<fallback-override>0</fallback-override>
<fallback-when-full>0</fallback-when-full>
<public>1</public>
<max-listeners>50</max-listeners>
<fallback-mount></fallback-mount>
</mount>
<fileserve>1</fileserver>
<paths>
<basedir>/usr/local/centovacast/var/vhosts/tester/</basedir>
<logdir>var/log/</logdir>
<webroot>web/</webroot>
<adminroot>admin/</adminroot>
<pidfile>var/run/server.pid</pidfile>
<alias source="/" dest="/status.xsl"></alias>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<playlistlog>playlist.log</playlistlog>
<loglevel>2</loglevel>
<!-- 4 Debug, 3 Info, 2 Warn, 1 Error -->
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>

Answer 1

Try to increase the queue-size and burst-size:
<queue-size>1048576</queue-size>
<burst-size>943718</burst-size>
I can´t explain it clearly, but you can follow this thread: https://www.internet-radio.com/community/threads/very-slow-buffering-in-android.20139/

Answer 2

When MP3 is streamed, it is segmented arbitrarily and sent as-is. That is, Icecast doesn't do any inspection or alignment of frames, meaning there can be a slight delay on the client when re-syncing to servers with small buffers.
However, a delay of a minute is an extremely long time. There was an issue with LAME (3.99.1 I think?) which was creating streams that Chrome had difficulty syncing to. You didn't mention what encoder you're using, but if it's using LAME, try upgrading or downgrading the version. If you're using something else, try switching to LAME. Also, try different browsers to see if you're getting this problem just in Chrome.
Progressive MP3 over HTTP (same as your setup) is the most common form of internet radio, and it can work just fine if set up correctly.